From: Greg Kroah-Hartman Date: Mon, 15 Nov 2021 13:00:33 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v5.4.160~62 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bbb234aaa1f7c686e4e908afb099909d5932d893;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: arm-9155-1-fix-early-early_iounmap.patch arm-9156-1-drop-cc-option-fallbacks-for-architecture-selection.patch parisc-fix-backtrace-to-always-include-init-funtion-names.patch parisc-fix-set_fixmap-on-pa1.x-cpus.patch --- diff --git a/queue-5.4/arm-9155-1-fix-early-early_iounmap.patch b/queue-5.4/arm-9155-1-fix-early-early_iounmap.patch new file mode 100644 index 00000000000..078bef155be --- /dev/null +++ b/queue-5.4/arm-9155-1-fix-early-early_iounmap.patch @@ -0,0 +1,40 @@ +From 0d08e7bf0d0d1a29aff7b16ef516f7415eb1aa05 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= +Date: Thu, 4 Nov 2021 17:28:28 +0100 +Subject: ARM: 9155/1: fix early early_iounmap() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michał Mirosław + +commit 0d08e7bf0d0d1a29aff7b16ef516f7415eb1aa05 upstream. + +Currently __set_fixmap() bails out with a warning when called in early boot +from early_iounmap(). Fix it, and while at it, make the comment a bit easier +to understand. + +Cc: +Fixes: b089c31c519c ("ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap") +Acked-by: Ard Biesheuvel +Signed-off-by: Michał Mirosław +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/mm/mmu.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm/mm/mmu.c ++++ b/arch/arm/mm/mmu.c +@@ -415,9 +415,9 @@ void __set_fixmap(enum fixed_addresses i + FIXADDR_END); + BUG_ON(idx >= __end_of_fixed_addresses); + +- /* we only support device mappings until pgprot_kernel has been set */ ++ /* We support only device mappings before pgprot_kernel is set. */ + if (WARN_ON(pgprot_val(prot) != pgprot_val(FIXMAP_PAGE_IO) && +- pgprot_val(pgprot_kernel) == 0)) ++ pgprot_val(prot) && pgprot_val(pgprot_kernel) == 0)) + return; + + if (pgprot_val(prot)) diff --git a/queue-5.4/arm-9156-1-drop-cc-option-fallbacks-for-architecture-selection.patch b/queue-5.4/arm-9156-1-drop-cc-option-fallbacks-for-architecture-selection.patch new file mode 100644 index 00000000000..9b738c826f4 --- /dev/null +++ b/queue-5.4/arm-9156-1-drop-cc-option-fallbacks-for-architecture-selection.patch @@ -0,0 +1,103 @@ +From 418ace9992a7647c446ed3186df40cf165b67298 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Sat, 6 Nov 2021 19:42:29 +0100 +Subject: ARM: 9156/1: drop cc-option fallbacks for architecture selection + +From: Arnd Bergmann + +commit 418ace9992a7647c446ed3186df40cf165b67298 upstream. + +Naresh and Antonio ran into a build failure with latest Debian +armhf compilers, with lots of output like + + tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode + +As it turns out, $(cc-option) fails early here when the FPU is not +selected before CPU architecture is selected, as the compiler +option check runs before enabling -msoft-float, which causes +a problem when testing a target architecture level without an FPU: + +cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU + +Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this +issue, but the fallback logic is already broken because all supported +compilers (gcc-5 and higher) are much more recent than these options, +and building with -march=armv5t as a fallback no longer works. + +The best way forward that I see is to just remove all the checks, which +also has the nice side-effect of slightly improving the startup time for +'make'. + +The -mtune=marvell-f option was apparently never supported by any mainline +compiler, and the custom Codesourcery gcc build that did support is +now too old to build kernels, so just use -mtune=xscale unconditionally +for those. + +This should be safe to apply on all stable kernels, and will be required +in order to keep building them with gcc-11 and higher. + +Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 + +Reported-by: Antonio Terceiro +Reported-by: Naresh Kamboju +Reported-by: Sebastian Andrzej Siewior +Tested-by: Sebastian Reichel +Tested-by: Klaus Kudielka +Cc: Matthias Klose +Cc: stable@vger.kernel.org +Signed-off-by: Arnd Bergmann +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/Makefile | 22 +++++++++++----------- + 1 file changed, 11 insertions(+), 11 deletions(-) + +--- a/arch/arm/Makefile ++++ b/arch/arm/Makefile +@@ -66,15 +66,15 @@ KBUILD_CFLAGS += $(call cc-option,-fno-i + # Note that GCC does not numerically define an architecture version + # macro, but instead defines a whole series of macros which makes + # testing for a specific architecture or later rather impossible. +-arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m +-arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) +-arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) ++arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m ++arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a ++arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 -march=armv6 + # Only override the compiler option if ARMv6. The ARMv6K extensions are + # always available in ARMv7 + ifeq ($(CONFIG_CPU_32v6),y) +-arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k) ++arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 -march=armv6k + endif +-arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t) ++arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 -march=armv5te + arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t + arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4 + arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3m +@@ -88,7 +88,7 @@ tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7t + tune-$(CONFIG_CPU_ARM740T) =-mtune=arm7tdmi + tune-$(CONFIG_CPU_ARM9TDMI) =-mtune=arm9tdmi + tune-$(CONFIG_CPU_ARM940T) =-mtune=arm9tdmi +-tune-$(CONFIG_CPU_ARM946E) =$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi) ++tune-$(CONFIG_CPU_ARM946E) =-mtune=arm9e + tune-$(CONFIG_CPU_ARM920T) =-mtune=arm9tdmi + tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi + tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi +@@ -96,11 +96,11 @@ tune-$(CONFIG_CPU_ARM926T) =-mtune=arm9t + tune-$(CONFIG_CPU_FA526) =-mtune=arm9tdmi + tune-$(CONFIG_CPU_SA110) =-mtune=strongarm110 + tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100 +-tune-$(CONFIG_CPU_XSCALE) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale +-tune-$(CONFIG_CPU_XSC3) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale +-tune-$(CONFIG_CPU_FEROCEON) =$(call cc-option,-mtune=marvell-f,-mtune=xscale) +-tune-$(CONFIG_CPU_V6) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) +-tune-$(CONFIG_CPU_V6K) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) ++tune-$(CONFIG_CPU_XSCALE) =-mtune=xscale ++tune-$(CONFIG_CPU_XSC3) =-mtune=xscale ++tune-$(CONFIG_CPU_FEROCEON) =-mtune=xscale ++tune-$(CONFIG_CPU_V6) =-mtune=arm1136j-s ++tune-$(CONFIG_CPU_V6K) =-mtune=arm1136j-s + + # Evaluate tune cc-option calls now + tune-y := $(tune-y) diff --git a/queue-5.4/parisc-fix-backtrace-to-always-include-init-funtion-names.patch b/queue-5.4/parisc-fix-backtrace-to-always-include-init-funtion-names.patch new file mode 100644 index 00000000000..b212e35719c --- /dev/null +++ b/queue-5.4/parisc-fix-backtrace-to-always-include-init-funtion-names.patch @@ -0,0 +1,57 @@ +From 279917e27edc293eb645a25428c6ab3f3bca3f86 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Thu, 4 Nov 2021 20:19:00 +0100 +Subject: parisc: Fix backtrace to always include init funtion names + +From: Helge Deller + +commit 279917e27edc293eb645a25428c6ab3f3bca3f86 upstream. + +I noticed that sometimes at kernel startup the backtraces did not +included the function names of init functions. Their address were not +resolved to function names and instead only the address was printed. + +Debugging shows that the culprit is is_ksym_addr() which is called +by the backtrace functions to check if an address belongs to a function in +the kernel. The problem occurs only for CONFIG_KALLSYMS_ALL=y. + +When looking at is_ksym_addr() one can see that for CONFIG_KALLSYMS_ALL=y +the function only tries to resolve the address via is_kernel() function, +which checks like this: + if (addr >= _stext && addr <= _end) + return 1; +On parisc the init functions are located before _stext, so this check fails. +Other platforms seem to have all functions (including init functions) +behind _stext. + +The following patch moves the _stext symbol at the beginning of the +kernel and thus includes the init section. This fixes the check and does +not seem to have any negative side effects on where the kernel mapping +happens in the map_pages() function in arch/parisc/mm/init.c. + +Signed-off-by: Helge Deller +Cc: stable@kernel.org # 5.4+ +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/kernel/vmlinux.lds.S | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/parisc/kernel/vmlinux.lds.S ++++ b/arch/parisc/kernel/vmlinux.lds.S +@@ -56,6 +56,8 @@ SECTIONS + { + . = KERNEL_BINARY_TEXT_START; + ++ _stext = .; /* start of kernel text, includes init code & data */ ++ + __init_begin = .; + HEAD_TEXT_SECTION + MLONGCALL_DISCARD(INIT_TEXT_SECTION(8)) +@@ -79,7 +81,6 @@ SECTIONS + /* freed after init ends here */ + + _text = .; /* Text and read-only data */ +- _stext = .; + MLONGCALL_KEEP(INIT_TEXT_SECTION(8)) + .text ALIGN(PAGE_SIZE) : { + TEXT_TEXT diff --git a/queue-5.4/parisc-fix-set_fixmap-on-pa1.x-cpus.patch b/queue-5.4/parisc-fix-set_fixmap-on-pa1.x-cpus.patch new file mode 100644 index 00000000000..e49a50c76ce --- /dev/null +++ b/queue-5.4/parisc-fix-set_fixmap-on-pa1.x-cpus.patch @@ -0,0 +1,38 @@ +From 6e866a462867b60841202e900f10936a0478608c Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Sun, 31 Oct 2021 21:58:12 +0100 +Subject: parisc: Fix set_fixmap() on PA1.x CPUs + +From: Helge Deller + +commit 6e866a462867b60841202e900f10936a0478608c upstream. + +Fix a kernel crash which happens on PA1.x CPUs while initializing the +FTRACE/KPROBE breakpoints. The PTE table entries for the fixmap area +were not created correctly. + +Signed-off-by: Helge Deller +Fixes: ccfbc68d41c2 ("parisc: add set_fixmap()/clear_fixmap()") +Cc: stable@vger.kernel.org # v5.2+ +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/mm/fixmap.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +--- a/arch/parisc/mm/fixmap.c ++++ b/arch/parisc/mm/fixmap.c +@@ -18,12 +18,9 @@ void notrace set_fixmap(enum fixed_addre + pte_t *pte; + + if (pmd_none(*pmd)) +- pmd = pmd_alloc(NULL, pgd, vaddr); +- +- pte = pte_offset_kernel(pmd, vaddr); +- if (pte_none(*pte)) + pte = pte_alloc_kernel(pmd, vaddr); + ++ pte = pte_offset_kernel(pmd, vaddr); + set_pte_at(&init_mm, vaddr, pte, __mk_pte(phys, PAGE_KERNEL_RWX)); + flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE); + } diff --git a/queue-5.4/series b/queue-5.4/series index e688928cee0..08cd099139b 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -332,3 +332,7 @@ vsock-prevent-unnecessary-refcnt-inc-for-nonblocking.patch net-smc-fix-sk_refcnt-underflow-on-linkdown-and-fall.patch cxgb4-fix-eeprom-len-when-diagnostics-not-implemente.patch selftests-net-udpgso_bench_rx-fix-port-argument.patch +arm-9155-1-fix-early-early_iounmap.patch +arm-9156-1-drop-cc-option-fallbacks-for-architecture-selection.patch +parisc-fix-backtrace-to-always-include-init-funtion-names.patch +parisc-fix-set_fixmap-on-pa1.x-cpus.patch