From 3558171b07dcf328c4d2e4437e2efe1bf281f902 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 5 Aug 2019 13:57:47 +0200 Subject: [PATCH] 4.14-stable patches added patches: gcc-9-properly-declare-the-pv-hv-clock_page-storage.patch objtool-support-gcc-9-cold-subfunction-naming-scheme.patch x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch --- ...declare-the-pv-hv-clock_page-storage.patch | 49 ++++++++++++++ ...gcc-9-cold-subfunction-naming-scheme.patch | 51 ++++++++++++++ queue-4.14/series | 3 + ...egfaults-due-to-hoisted-vclock-reads.patch | 67 +++++++++++++++++++ 4 files changed, 170 insertions(+) create mode 100644 queue-4.14/gcc-9-properly-declare-the-pv-hv-clock_page-storage.patch create mode 100644 queue-4.14/objtool-support-gcc-9-cold-subfunction-naming-scheme.patch create mode 100644 queue-4.14/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch diff --git a/queue-4.14/gcc-9-properly-declare-the-pv-hv-clock_page-storage.patch b/queue-4.14/gcc-9-properly-declare-the-pv-hv-clock_page-storage.patch new file mode 100644 index 00000000000..a49d049ab43 --- /dev/null +++ b/queue-4.14/gcc-9-properly-declare-the-pv-hv-clock_page-storage.patch @@ -0,0 +1,49 @@ +From 459e3a21535ae3c7a9a123650e54f5c882b8fcbf Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Wed, 1 May 2019 11:20:53 -0700 +Subject: gcc-9: properly declare the {pv,hv}clock_page storage +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Linus Torvalds + +commit 459e3a21535ae3c7a9a123650e54f5c882b8fcbf upstream. + +The pvlock_page and hvclock_page variables are (as the name implies) +addresses to pages, created by the linker script. + +But we declared them as just "extern u8" variables, which _works_, but +now that gcc does some more bounds checking, it causes warnings like + + warning: array subscript 1 is outside array bounds of ‘u8[1]’ + +when we then access more than one byte from those variables. + +Fix this by simply making the declaration of the variables match +reality, which makes the compiler happy too. + +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/entry/vdso/vclock_gettime.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/entry/vdso/vclock_gettime.c ++++ b/arch/x86/entry/vdso/vclock_gettime.c +@@ -29,12 +29,12 @@ extern int __vdso_gettimeofday(struct ti + extern time_t __vdso_time(time_t *t); + + #ifdef CONFIG_PARAVIRT_CLOCK +-extern u8 pvclock_page ++extern u8 pvclock_page[PAGE_SIZE] + __attribute__((visibility("hidden"))); + #endif + + #ifdef CONFIG_HYPERV_TSCPAGE +-extern u8 hvclock_page ++extern u8 hvclock_page[PAGE_SIZE] + __attribute__((visibility("hidden"))); + #endif + diff --git a/queue-4.14/objtool-support-gcc-9-cold-subfunction-naming-scheme.patch b/queue-4.14/objtool-support-gcc-9-cold-subfunction-naming-scheme.patch new file mode 100644 index 00000000000..cb2cb7e6130 --- /dev/null +++ b/queue-4.14/objtool-support-gcc-9-cold-subfunction-naming-scheme.patch @@ -0,0 +1,51 @@ +From bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6 Mon Sep 17 00:00:00 2001 +From: Josh Poimboeuf +Date: Wed, 31 Oct 2018 21:57:30 -0500 +Subject: objtool: Support GCC 9 cold subfunction naming scheme + +From: Josh Poimboeuf + +commit bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6 upstream. + +Starting with GCC 8, a lot of unlikely code was moved out of line to +"cold" subfunctions in .text.unlikely. + +For example, the unlikely bits of: + + irq_do_set_affinity() + +are moved out to the following subfunction: + + irq_do_set_affinity.cold.49() + +Starting with GCC 9, the numbered suffix has been removed. So in the +above example, the cold subfunction is instead: + + irq_do_set_affinity.cold() + +Tweak the objtool subfunction detection logic so that it detects both +GCC 8 and GCC 9 naming schemes. + +Reported-by: Peter Zijlstra (Intel) +Signed-off-by: Josh Poimboeuf +Signed-off-by: Thomas Gleixner +Tested-by: Peter Zijlstra (Intel) +Acked-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/015e9544b1f188d36a7f02fa31e9e95629aa5f50.1541040800.git.jpoimboe@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + tools/objtool/elf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/objtool/elf.c ++++ b/tools/objtool/elf.c +@@ -305,7 +305,7 @@ static int read_symbols(struct elf *elf) + if (sym->type != STT_FUNC) + continue; + sym->pfunc = sym->cfunc = sym; +- coldstr = strstr(sym->name, ".cold."); ++ coldstr = strstr(sym->name, ".cold"); + if (!coldstr) + continue; + diff --git a/queue-4.14/series b/queue-4.14/series index 4aa183f1b77..90a9aeff8e1 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -48,3 +48,6 @@ ib-mlx5-move-mrs-to-a-kernel-pd-when-freeing-them-to-the-mr-cache.patch ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch ib-hfi1-check-for-error-on-call-to-alloc_rsm_map_table.patch eeprom-at24-make-spd-world-readable-again.patch +objtool-support-gcc-9-cold-subfunction-naming-scheme.patch +gcc-9-properly-declare-the-pv-hv-clock_page-storage.patch +x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch diff --git a/queue-4.14/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch b/queue-4.14/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch new file mode 100644 index 00000000000..47215e08b50 --- /dev/null +++ b/queue-4.14/x86-vdso-prevent-segfaults-due-to-hoisted-vclock-reads.patch @@ -0,0 +1,67 @@ +From ff17bbe0bb405ad8b36e55815d381841f9fdeebc Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Fri, 21 Jun 2019 08:43:04 -0700 +Subject: x86/vdso: Prevent segfaults due to hoisted vclock reads + +From: Andy Lutomirski + +commit ff17bbe0bb405ad8b36e55815d381841f9fdeebc upstream. + +GCC 5.5.0 sometimes cleverly hoists reads of the pvclock and/or hvclock +pages before the vclock mode checks. This creates a path through +vclock_gettime() in which no vclock is enabled at all (due to disabled +TSC on old CPUs, for example) but the pvclock or hvclock page +nevertheless read. This will segfault on bare metal. + +This fixes commit 459e3a21535a ("gcc-9: properly declare the +{pv,hv}clock_page storage") in the sense that, before that commit, GCC +didn't seem to generate the offending code. There was nothing wrong +with that commit per se, and -stable maintainers should backport this to +all supported kernels regardless of whether the offending commit was +present, since the same crash could just as easily be triggered by the +phase of the moon. + +On GCC 9.1.1, this doesn't seem to affect the generated code at all, so +I'm not too concerned about performance regressions from this fix. + +Cc: stable@vger.kernel.org +Cc: x86@kernel.org +Cc: Borislav Petkov +Reported-by: Duncan Roe +Signed-off-by: Andy Lutomirski +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/entry/vdso/vclock_gettime.c | 15 +++++++++++++-- + 1 file changed, 13 insertions(+), 2 deletions(-) + +--- a/arch/x86/entry/vdso/vclock_gettime.c ++++ b/arch/x86/entry/vdso/vclock_gettime.c +@@ -191,13 +191,24 @@ notrace static inline u64 vgetsns(int *m + + if (gtod->vclock_mode == VCLOCK_TSC) + cycles = vread_tsc(); ++ ++ /* ++ * For any memory-mapped vclock type, we need to make sure that gcc ++ * doesn't cleverly hoist a load before the mode check. Otherwise we ++ * might end up touching the memory-mapped page even if the vclock in ++ * question isn't enabled, which will segfault. Hence the barriers. ++ */ + #ifdef CONFIG_PARAVIRT_CLOCK +- else if (gtod->vclock_mode == VCLOCK_PVCLOCK) ++ else if (gtod->vclock_mode == VCLOCK_PVCLOCK) { ++ barrier(); + cycles = vread_pvclock(mode); ++ } + #endif + #ifdef CONFIG_HYPERV_TSCPAGE +- else if (gtod->vclock_mode == VCLOCK_HVCLOCK) ++ else if (gtod->vclock_mode == VCLOCK_HVCLOCK) { ++ barrier(); + cycles = vread_hvclock(mode); ++ } + #endif + else + return 0; -- 2.47.3