]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
drop kasan patch
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 21 Feb 2019 16:08:38 +0000 (17:08 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 21 Feb 2019 16:08:38 +0000 (17:08 +0100)
queue-4.19/series
queue-4.19/x86_64-increase-stack-size-for-kasan_extra.patch [deleted file]
queue-4.20/series
queue-4.20/x86_64-increase-stack-size-for-kasan_extra.patch [deleted file]

index 95b2c2ab27354a957f51ece96156b93883dacac6..cd1d16222d26716921f4575a4e28139c1f7cde66 100644 (file)
@@ -20,7 +20,6 @@ tcp-tcp_v4_err-should-be-more-careful.patch
 net-do-not-allocate-page-fragments-that-are-not-skb-.patch
 hwmon-lm80-fix-missing-unlock-on-error-in-set_fan_div.patch
 scsi-target-core-use-kmem_cache_free-instead-of-kfree.patch
-x86_64-increase-stack-size-for-kasan_extra.patch
 mmc-meson-gx-fix-interrupt-name.patch
 pci-fix-__initdata-issue-with-pci-disable_acs_redir-parameter.patch
 sunrpc-fix-4-more-call-sites-that-were-using-stack-memory-with-a-scatterlist.patch
diff --git a/queue-4.19/x86_64-increase-stack-size-for-kasan_extra.patch b/queue-4.19/x86_64-increase-stack-size-for-kasan_extra.patch
deleted file mode 100644 (file)
index 2ec7987..0000000
+++ /dev/null
@@ -1,80 +0,0 @@
-From a8e911d13540487942d53137c156bd7707f66e5d Mon Sep 17 00:00:00 2001
-From: Qian Cai <cai@lca.pw>
-Date: Fri, 1 Feb 2019 14:20:20 -0800
-Subject: x86_64: increase stack size for KASAN_EXTRA
-
-From: Qian Cai <cai@lca.pw>
-
-commit a8e911d13540487942d53137c156bd7707f66e5d upstream.
-
-If the kernel is configured with KASAN_EXTRA, the stack size is
-increasted significantly because this option sets "-fstack-reuse" to
-"none" in GCC [1].  As a result, it triggers stack overrun quite often
-with 32k stack size compiled using GCC 8.  For example, this reproducer
-
-  https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c
-
-triggers a "corrupted stack end detected inside scheduler" very reliably
-with CONFIG_SCHED_STACK_END_CHECK enabled.
-
-There are just too many functions that could have a large stack with
-KASAN_EXTRA due to large local variables that have been called over and
-over again without being able to reuse the stacks.  Some noticiable ones
-are
-
-  size
-  7648 shrink_page_list
-  3584 xfs_rmap_convert
-  3312 migrate_page_move_mapping
-  3312 dev_ethtool
-  3200 migrate_misplaced_transhuge_page
-  3168 copy_process
-
-There are other 49 functions are over 2k in size while compiling kernel
-with "-Wframe-larger-than=" even with a related minimal config on this
-machine.  Hence, it is too much work to change Makefiles for each object
-to compile without "-fsanitize-address-use-after-scope" individually.
-
-[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23
-
-Although there is a patch in GCC 9 to help the situation, GCC 9 probably
-won't be released in a few months and then it probably take another
-6-month to 1-year for all major distros to include it as a default.
-Hence, the stack usage with KASAN_EXTRA can be revisited again in 2020
-when GCC 9 is everywhere.  Until then, this patch will help users avoid
-stack overrun.
-
-This has already been fixed for arm64 for the same reason via
-6e8830674ea ("arm64: kasan: Increase stack size for KASAN_EXTRA").
-
-Link: http://lkml.kernel.org/r/20190109215209.2903-1-cai@lca.pw
-Signed-off-by: Qian Cai <cai@lca.pw>
-Cc: Thomas Gleixner <tglx@linutronix.de>
-Cc: Ingo Molnar <mingo@redhat.com>
-Cc: Borislav Petkov <bp@alien8.de>
-Cc: "H. Peter Anvin" <hpa@zytor.com>
-Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
-Cc: Alexander Potapenko <glider@google.com>
-Cc: Dmitry Vyukov <dvyukov@google.com>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- arch/x86/include/asm/page_64_types.h |    4 ++++
- 1 file changed, 4 insertions(+)
-
---- a/arch/x86/include/asm/page_64_types.h
-+++ b/arch/x86/include/asm/page_64_types.h
-@@ -7,7 +7,11 @@
- #endif
- #ifdef CONFIG_KASAN
-+#ifdef CONFIG_KASAN_EXTRA
-+#define KASAN_STACK_ORDER 2
-+#else
- #define KASAN_STACK_ORDER 1
-+#endif
- #else
- #define KASAN_STACK_ORDER 0
- #endif
index 51a66ae209145710b6128acb178bac11a7567903..f93cd6298fbc8180b31d4c77c7146ec33a188fae 100644 (file)
@@ -23,7 +23,6 @@ arm64-mm-efi-account-for-gicv3-lpi-tables-in-static-.patch
 efi-arm-revert-defer-persistent-reservations-until-a.patch
 pci-fix-__initdata-issue-with-pci-disable_acs_redir-.patch
 scsi-target-core-use-kmem_cache_free-instead-of-kfre.patch
-x86_64-increase-stack-size-for-kasan_extra.patch
 mmc-meson-gx-fix-interrupt-name.patch
 hwmon-lm80-fix-missing-unlock-on-error-in-set_fan_di.patch
 netfilter-nf_nat_snmp_basic-add-missing-length-checks-in-asn.1-cbs.patch
diff --git a/queue-4.20/x86_64-increase-stack-size-for-kasan_extra.patch b/queue-4.20/x86_64-increase-stack-size-for-kasan_extra.patch
deleted file mode 100644 (file)
index bc92376..0000000
+++ /dev/null
@@ -1,82 +0,0 @@
-From 67fd2fd35761d6bb8dcebe5070960c2f0baaef69 Mon Sep 17 00:00:00 2001
-From: Qian Cai <cai@lca.pw>
-Date: Fri, 1 Feb 2019 14:20:20 -0800
-Subject: x86_64: increase stack size for KASAN_EXTRA
-
-[ Upstream commit a8e911d13540487942d53137c156bd7707f66e5d ]
-
-If the kernel is configured with KASAN_EXTRA, the stack size is
-increasted significantly because this option sets "-fstack-reuse" to
-"none" in GCC [1].  As a result, it triggers stack overrun quite often
-with 32k stack size compiled using GCC 8.  For example, this reproducer
-
-  https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c
-
-triggers a "corrupted stack end detected inside scheduler" very reliably
-with CONFIG_SCHED_STACK_END_CHECK enabled.
-
-There are just too many functions that could have a large stack with
-KASAN_EXTRA due to large local variables that have been called over and
-over again without being able to reuse the stacks.  Some noticiable ones
-are
-
-  size
-  7648 shrink_page_list
-  3584 xfs_rmap_convert
-  3312 migrate_page_move_mapping
-  3312 dev_ethtool
-  3200 migrate_misplaced_transhuge_page
-  3168 copy_process
-
-There are other 49 functions are over 2k in size while compiling kernel
-with "-Wframe-larger-than=" even with a related minimal config on this
-machine.  Hence, it is too much work to change Makefiles for each object
-to compile without "-fsanitize-address-use-after-scope" individually.
-
-[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23
-
-Although there is a patch in GCC 9 to help the situation, GCC 9 probably
-won't be released in a few months and then it probably take another
-6-month to 1-year for all major distros to include it as a default.
-Hence, the stack usage with KASAN_EXTRA can be revisited again in 2020
-when GCC 9 is everywhere.  Until then, this patch will help users avoid
-stack overrun.
-
-This has already been fixed for arm64 for the same reason via
-6e8830674ea ("arm64: kasan: Increase stack size for KASAN_EXTRA").
-
-Link: http://lkml.kernel.org/r/20190109215209.2903-1-cai@lca.pw
-Signed-off-by: Qian Cai <cai@lca.pw>
-Cc: Thomas Gleixner <tglx@linutronix.de>
-Cc: Ingo Molnar <mingo@redhat.com>
-Cc: Borislav Petkov <bp@alien8.de>
-Cc: "H. Peter Anvin" <hpa@zytor.com>
-Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
-Cc: Alexander Potapenko <glider@google.com>
-Cc: Dmitry Vyukov <dvyukov@google.com>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- arch/x86/include/asm/page_64_types.h | 4 ++++
- 1 file changed, 4 insertions(+)
-
-diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
-index 8f657286d599a..0ce558a8150d3 100644
---- a/arch/x86/include/asm/page_64_types.h
-+++ b/arch/x86/include/asm/page_64_types.h
-@@ -7,7 +7,11 @@
- #endif
- #ifdef CONFIG_KASAN
-+#ifdef CONFIG_KASAN_EXTRA
-+#define KASAN_STACK_ORDER 2
-+#else
- #define KASAN_STACK_ORDER 1
-+#endif
- #else
- #define KASAN_STACK_ORDER 0
- #endif
--- 
-2.19.1
-