June 2021 - Linux-stable-mirror

[PATCH stable v5.4] arm64: link with -z norelro for LLD or aarch64-elf

by Jisheng Zhang

From: Nick Desaulniers <ndesaulniers(a)google.com> commit 311bea3cb9ee20ef150ca76fc60a592bf6b159f5 upstream. With GNU binutils 2.35+, linking with BFD produces warnings for vmlinux: aarch64-linux-gnu-ld: warning: -z norelro ignored BFD can produce this warning when the target emulation mode does not support RELRO program headers, and -z relro or -z norelro is passed. Alan Modra clarifies: The default linker emulation for an aarch64-linux ld.bfd is -maarch64linux, the default for an aarch64-elf linker is -maarch64elf. They are not equivalent. If you choose -maarch64elf you get an emulation that doesn't support -z relro. The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to -maarch64linux based on the toolchain configuration. LLD will always create RELRO program header regardless of target emulation. To avoid the above warning when linking with BFD, pass -z norelro only when linking with LLD or with -maarch64linux. Fixes: 3b92fa7485eb ("arm64: link with -z norelro regardless of CONFIG_RELOCATABLE") Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options") Cc: <stable(a)vger.kernel.org> # 5.0.x- Reported-by: kernelci.org bot <bot(a)kernelci.org> Reported-by: Quentin Perret <qperret(a)google.com> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Reviewed-by: Nathan Chancellor <natechancellor(a)gmail.com> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Cc: Alan Modra <amodra(a)gmail.com> Cc: Fāng-ruì Sòng <maskray(a)google.com> Link: https://lore.kernel.org/r/20201218002432.788499-1-ndesaulniers@google.com Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> --- arch/arm64/Makefile | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index cd8f3cdabfd0..d227cf87c48f 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -10,7 +10,7 @@ # # Copyright (C) 1995-2001 by Russell King -LDFLAGS_vmlinux :=--no-undefined -X -z norelro +LDFLAGS_vmlinux :=--no-undefined -X CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET) GZFLAGS :=-9 @@ -82,17 +82,21 @@ CHECKFLAGS += -D__AARCH64EB__ AS += -EB # Prefer the baremetal ELF build target, but not all toolchains include # it so fall back to the standard linux version if needed. -KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb) +KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb -z norelro) UTS_MACHINE := aarch64_be else KBUILD_CPPFLAGS += -mlittle-endian CHECKFLAGS += -D__AARCH64EL__ AS += -EL # Same as above, prefer ELF but fall back to linux target if needed. -KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux) +KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux -z norelro) UTS_MACHINE := aarch64 endif +ifeq ($(CONFIG_LD_IS_LLD), y) +KBUILD_LDFLAGS += -z norelro +endif + CHECKFLAGS += -D__aarch64__ ifeq ($(CONFIG_ARM64_MODULE_PLTS),y) -- 2.32.0

3 years, 3 months

3
4
0 0

[v4.14.y] 3cce50dfec4a arm64: perf: Disable PMU while processing counter overflows

by Aman Priyadarshi

Hi Greg, Following the conversation with Marc, we discovered that an important fix for ARM PMU is not backported to 4.14.y tree, it affects counter value and give out nonsensical result. Can you please include the following commit? ``` commit 3cce50dfec4a5b0414c974190940f47dd32c6dee Author: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Tue Jul 10 09:58:03 2018 +0100 arm64: perf: Disable PMU while processing counter overflows The arm64 PMU updates the event counters and reprograms the counters in the overflow IRQ handler without disabling the PMU. This could potentially cause skews in for group counters, where the overflowed counters may potentially loose some event counts, while they are reprogrammed. To prevent this, disable the PMU while we process the counter overflows and enable it right back when we are done. This patch also moves the PMU stop/start routines to avoid a forward declaration. Suggested-by: Mark Rutland <mark.rutland(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> ``` For more details: https://lists.cs.columbia.edu/pipermail/kvmarm/2021-June/047471.html Regards, Aman Priyadarshi Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879

3 years, 3 months

3
6
0 0

Backport of e607ff630c60 for 4.14 to 5.10

by Nathan Chancellor

Hi Greg and Sasha, Please find attached backports for commit e607ff630c60 ("MIPS: generic: Update node names to avoid unit addresses"). It has already been applied to 5.12 but it is missing from all other branches that need it. Let me know if there are any issues with applying it. Cheers, Nathan

3 years, 3 months

2
1
0 0

[PATCH stable-v5.4 v2 0/2] properly cope with -z norelro

by Jisheng Zhang

Fix below build warning: aarch64-linux-gnu-ld: warning: -z norelro ignored Since v1 - Backport a preparation patch as pointed out by Nick Desaulniers Nick Desaulniers (1): arm64: link with -z norelro for LLD or aarch64-elf Sami Tolvanen (1): kbuild: add CONFIG_LD_IS_LLD arch/arm64/Makefile | 10 +++++++--- init/Kconfig | 3 +++ 2 files changed, 10 insertions(+), 3 deletions(-) -- 2.32.0

3 years, 3 months

2
3
0 0

Backporting 3a7956e25e1d to LTS kernels?

by Jakub Jankowski

Hi, We've recently hit this on 5.4.124: WARNING: CPU: 5 PID: 35 at kernel/kthread.c:75 kthread_is_per_cpu+0x21/0x30 After some digging, I figured out that this should be fixed by commit 3a7956e25e1d ("kthread: Fix PF_KTHREAD vs to_kthread() race") in mainline. It Fixes: ac687e6e8c26 ("kthread: Extract KTHREAD_IS_PER_CPU") 3a7956e25e1d has been backported to 5.12.x and 5.11.x: - 5.12.4: as 163dd7fa459faebe055bcbebf9e088bae04f8e33 - 5.11.21: as 42e4caa93282ade6a143ff320d71062874dd3a5a Makes sense, as ac687e6e8c26 originally landed in 5.11. But it appears that since then ac687e6e8c26 has also been backported to LTS trees: - 5.10.14: as b20475a80b4bd2c7bc720c3a9a8337c36b20dd8c - 5.4.96: as 5b1e4fc2984eab30c5fffbf2bd1f016577cadab6 - 4.19.174: as fbad32181af9c8c76698b16115c28a493c26a2ee - 4.14.220: as a9b2e4a94eee352e0b3e863045e7379d83131ee2 Maybe those trees could use a backport of 3a7956e25e1d as well then? Cheers, Jakub.

3 years, 3 months

2
1
0 0

[PATCH 4.4 to 4.19] Makefile: Move -Wno-unused-but-set-variable out of GCC only block

by Nathan Chancellor

commit 885480b084696331bea61a4f7eba10652999a9c1 upstream. Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: stable(a)vger.kernel.org Link: https://reviews.llvm.org/D100581 Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers(a)google.com> Tested-by: Nick Desaulniers <ndesaulniers(a)google.com> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> [nc: Backport, workaround lack of e2079e93f562 in older branches] Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 9ff7a4b7b8cb..cda7a18b925a 100644 --- a/Makefile +++ b/Makefile @@ -716,12 +716,11 @@ KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare) # See modpost pattern 2 KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,) KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior) -else +endif # These warnings generated too much noise in a regular build. # Use make W=1 to enable them (see scripts/Makefile.extrawarn) KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) -endif KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) ifdef CONFIG_FRAME_POINTER base-commit: eb575cd5d7f60241d016fdd13a9e86d962093c9b -- 2.32.0.93.g670b81a890

3 years, 3 months

3
3
0 0

Buying an item on your site

by mike＠wizzardzone.com

"Hello, We are interested in advertising. We want to advertise guest article on your site planet.kernel.org. Our article will be written according to your site theme and will include a link to a betting site. What is the rate for this? IMPORTANT: If you are not accepting links to gambling site we might be still interested, Please mention the rate for regular links as well Skype: shanker2020 Telegram 9966160005 WhatsApp number: 9966160005 Thank you"

3 years, 3 months

1
0
0 0

[PATCH 5.10 v2] KVM: SVM: Call SEV Guest Decommission if ASID binding fails

by Alper Gun

commit 934002cd660b035b926438244b4294e647507e13 upstream. Send SEV_CMD_DECOMMISSION command to PSP firmware if ASID binding fails. If a failure happens after a successful LAUNCH_START command, a decommission command should be executed. Otherwise, guest context will be unfreed inside the AMD SP. After the firmware will not have memory to allocate more SEV guest context, LAUNCH_START command will begin to fail with SEV_RET_RESOURCE_LIMIT error. The existing code calls decommission inside sev_unbind_asid, but it is not called if a failure happens before guest activation succeeds. If sev_bind_asid fails, decommission is never called. PSP firmware has a limit for the number of guests. If sev_asid_binding fails many times, PSP firmware will not have resources to create another guest context. Cc: stable(a)vger.kernel.org Fixes: 59414c989220 ("KVM: SVM: Add support for KVM_SEV_LAUNCH_START command") Reported-by: Peter Gonda <pgonda(a)google.com> Signed-off-by: Alper Gun <alpergun(a)google.com> Reviewed-by: Marc Orr <marcorr(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/kvm/svm/sev.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 16b10b9436dc..01547bdbfb06 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -130,9 +130,25 @@ static void sev_asid_free(int asid) mutex_unlock(&sev_bitmap_lock); } -static void sev_unbind_asid(struct kvm *kvm, unsigned int handle) +static void sev_decommission(unsigned int handle) { struct sev_data_decommission *decommission; + + if (!handle) + return; + + decommission = kzalloc(sizeof(*decommission), GFP_KERNEL); + if (!decommission) + return; + + decommission->handle = handle; + sev_guest_decommission(decommission, NULL); + + kfree(decommission); +} + +static void sev_unbind_asid(struct kvm *kvm, unsigned int handle) +{ struct sev_data_deactivate *data; if (!handle) @@ -152,15 +168,7 @@ static void sev_unbind_asid(struct kvm *kvm, unsigned int handle) kfree(data); - decommission = kzalloc(sizeof(*decommission), GFP_KERNEL); - if (!decommission) - return; - - /* decommission handle */ - decommission->handle = handle; - sev_guest_decommission(decommission, NULL); - - kfree(decommission); + sev_decommission(handle); } static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp) @@ -288,8 +296,10 @@ static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) /* Bind ASID to this guest */ ret = sev_bind_asid(kvm, start->handle, error); - if (ret) + if (ret) { + sev_decommission(start->handle); goto e_free_session; + } /* return handle to userspace */ params.handle = start->handle; -- 2.32.0.93.g670b81a890-goog

3 years, 3 months

2
1
0 0

patch "USB: cdc-acm: blacklist Heimann USB Appset device" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: cdc-acm: blacklist Heimann USB Appset device to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 4897807753e078655a78de39ed76044d784f3e63 Mon Sep 17 00:00:00 2001 From: Hannu Hartikainen <hannu(a)hrtk.in> Date: Tue, 22 Jun 2021 17:14:54 +0300 Subject: USB: cdc-acm: blacklist Heimann USB Appset device The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be a CDC-ACM device in its descriptors but in fact is not. If it is run with echo disabled it returns garbled data, probably due to something that happens in the TTY layer. And when run with echo enabled (the default), it will mess up the calibration data of the sensor the first time any data is sent to the device. In short, I had a bad time after connecting the sensor and trying to get it to work. I hope blacklisting it in the cdc-acm driver will save someone else a bit of trouble. Signed-off-by: Hannu Hartikainen <hannu(a)hrtk.in> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index ca7a61190dd9..d50b606d09aa 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1959,6 +1959,11 @@ static const struct usb_device_id acm_ids[] = { .driver_info = IGNORE_DEVICE, }, + /* Exclude Heimann Sensor GmbH USB appset demo */ + { USB_DEVICE(0x32a7, 0x0000), + .driver_info = IGNORE_DEVICE, + }, + /* control interfaces without any protocol set */ { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM, USB_CDC_PROTO_NONE) }, -- 2.32.0

3 years, 3 months

1
0
0 0

[patch 20/24] mm/hwpoison: do not lock page again when me_huge_page() successfully recovers

by Andrew Morton

From: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Subject: mm/hwpoison: do not lock page again when me_huge_page() successfully recovers Currently me_huge_page() temporary unlocks page to perform some actions then locks it again later. My testcase (which calls hard-offline on some tail page in a hugetlb, then accesses the address of the hugetlb range) showed that page allocation code detects this page lock on buddy page and printed out "BUG: Bad page state" message. check_new_page_bad() does not consider a page with __PG_HWPOISON as bad page, so this flag works as kind of filter, but this filtering doesn't work in this case because the "bad page" is not the actual hwpoisoned page. So stop locking page again. Actions to be taken depend on the page type of the error, so page unlocking should be done in ->action() callbacks. So let's make it assumed and change all existing callbacks that way. Link: https://lkml.kernel.org/r/20210609072029.74645-1-nao.horiguchi@gmail.com Fixes: commit 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory error") Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 44 ++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) --- a/mm/memory-failure.c~mm-hwpoison-do-not-lock-page-again-when-me_huge_page-successfully-recovers +++ a/mm/memory-failure.c @@ -658,6 +658,7 @@ static int truncate_error_page(struct pa */ static int me_kernel(struct page *p, unsigned long pfn) { + unlock_page(p); return MF_IGNORED; } @@ -667,6 +668,7 @@ static int me_kernel(struct page *p, uns static int me_unknown(struct page *p, unsigned long pfn) { pr_err("Memory failure: %#lx: Unknown page state\n", pfn); + unlock_page(p); return MF_FAILED; } @@ -675,6 +677,7 @@ static int me_unknown(struct page *p, un */ static int me_pagecache_clean(struct page *p, unsigned long pfn) { + int ret; struct address_space *mapping; delete_from_lru_cache(p); @@ -683,8 +686,10 @@ static int me_pagecache_clean(struct pag * For anonymous pages we're done the only reference left * should be the one m_f() holds. */ - if (PageAnon(p)) - return MF_RECOVERED; + if (PageAnon(p)) { + ret = MF_RECOVERED; + goto out; + } /* * Now truncate the page in the page cache. This is really @@ -698,7 +703,8 @@ static int me_pagecache_clean(struct pag /* * Page has been teared down in the meanwhile */ - return MF_FAILED; + ret = MF_FAILED; + goto out; } /* @@ -706,7 +712,10 @@ static int me_pagecache_clean(struct pag * * Open: to take i_mutex or not for this? Right now we don't. */ - return truncate_error_page(p, pfn, mapping); + ret = truncate_error_page(p, pfn, mapping); +out: + unlock_page(p); + return ret; } /* @@ -782,24 +791,26 @@ static int me_pagecache_dirty(struct pag */ static int me_swapcache_dirty(struct page *p, unsigned long pfn) { + int ret; + ClearPageDirty(p); /* Trigger EIO in shmem: */ ClearPageUptodate(p); - if (!delete_from_lru_cache(p)) - return MF_DELAYED; - else - return MF_FAILED; + ret = delete_from_lru_cache(p) ? MF_FAILED : MF_DELAYED; + unlock_page(p); + return ret; } static int me_swapcache_clean(struct page *p, unsigned long pfn) { + int ret; + delete_from_swap_cache(p); - if (!delete_from_lru_cache(p)) - return MF_RECOVERED; - else - return MF_FAILED; + ret = delete_from_lru_cache(p) ? MF_FAILED : MF_RECOVERED; + unlock_page(p); + return ret; } /* @@ -820,6 +831,7 @@ static int me_huge_page(struct page *p, mapping = page_mapping(hpage); if (mapping) { res = truncate_error_page(hpage, pfn, mapping); + unlock_page(hpage); } else { res = MF_FAILED; unlock_page(hpage); @@ -834,7 +846,6 @@ static int me_huge_page(struct page *p, page_ref_inc(p); res = MF_RECOVERED; } - lock_page(hpage); } return res; @@ -866,6 +877,8 @@ static struct page_state { unsigned long mask; unsigned long res; enum mf_action_page_type type; + + /* Callback ->action() has to unlock the relevant page inside it. */ int (*action)(struct page *p, unsigned long pfn); } error_states[] = { { reserved, reserved, MF_MSG_KERNEL, me_kernel }, @@ -929,6 +942,7 @@ static int page_action(struct page_state int result; int count; + /* page p should be unlocked after returning from ps->action(). */ result = ps->action(p, pfn); count = page_count(p) - 1; @@ -1313,7 +1327,7 @@ static int memory_failure_hugetlb(unsign goto out; } - res = identify_page_state(pfn, p, page_flags); + return identify_page_state(pfn, p, page_flags); out: unlock_page(head); return res; @@ -1596,6 +1610,8 @@ try_again: identify_page_state: res = identify_page_state(pfn, p, page_flags); + mutex_unlock(&mf_mutex); + return res; unlock_page: unlock_page(p); unlock_mutex: _

3 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2021