- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] x86/stackprotector: Work around strict Clang TLS symbol" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 577c134d311b9b94598d7a0c86be1f431f823003 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024111737-undead-acutely-d4b1@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 577c134d311b9b94598d7a0c86be1f431f823003 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ardb(a)kernel.org> Date: Tue, 5 Nov 2024 10:57:46 -0500 Subject: [PATCH] x86/stackprotector: Work around strict Clang TLS symbol requirements GCC and Clang both implement stack protector support based on Thread Local Storage (TLS) variables, and this is used in the kernel to implement per-task stack cookies, by copying a task's stack cookie into a per-CPU variable every time it is scheduled in. Both now also implement -mstack-protector-guard-symbol=, which permits the TLS variable to be specified directly. This is useful because it will allow to move away from using a fixed offset of 40 bytes into the per-CPU area on x86_64, which requires a lot of special handling in the per-CPU code and the runtime relocation code. However, while GCC is rather lax in its implementation of this command line option, Clang actually requires that the provided symbol name refers to a TLS variable (i.e., one declared with __thread), although it also permits the variable to be undeclared entirely, in which case it will use an implicit declaration of the right type. The upshot of this is that Clang will emit the correct references to the stack cookie variable in most cases, e.g., 10d: 64 a1 00 00 00 00 mov %fs:0x0,%eax 10f: R_386_32 __stack_chk_guard However, if a non-TLS definition of the symbol in question is visible in the same compilation unit (which amounts to the whole of vmlinux if LTO is enabled), it will drop the per-CPU prefix and emit a load from a bogus address. Work around this by using a symbol name that never occurs in C code, and emit it as an alias in the linker script. Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable") Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Brian Gerst <brgerst(a)gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Nathan Chancellor <nathan(a)kernel.org> Tested-by: Nathan Chancellor <nathan(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1854 Link: https://lore.kernel.org/r/20241105155801.1779119-2-brgerst@gmail.com diff --git a/arch/x86/Makefile b/arch/x86/Makefile index cd75e78a06c1..5b773b34768d 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -142,9 +142,10 @@ ifeq ($(CONFIG_X86_32),y) ifeq ($(CONFIG_STACKPROTECTOR),y) ifeq ($(CONFIG_SMP),y) - KBUILD_CFLAGS += -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard + KBUILD_CFLAGS += -mstack-protector-guard-reg=fs \ + -mstack-protector-guard-symbol=__ref_stack_chk_guard else - KBUILD_CFLAGS += -mstack-protector-guard=global + KBUILD_CFLAGS += -mstack-protector-guard=global endif endif else diff --git a/arch/x86/entry/entry.S b/arch/x86/entry/entry.S index 324686bca368..b7ea3e8e9ecc 100644 --- a/arch/x86/entry/entry.S +++ b/arch/x86/entry/entry.S @@ -51,3 +51,19 @@ EXPORT_SYMBOL_GPL(mds_verw_sel); .popsection THUNK warn_thunk_thunk, __warn_thunk + +#ifndef CONFIG_X86_64 +/* + * Clang's implementation of TLS stack cookies requires the variable in + * question to be a TLS variable. If the variable happens to be defined as an + * ordinary variable with external linkage in the same compilation unit (which + * amounts to the whole of vmlinux with LTO enabled), Clang will drop the + * segment register prefix from the references, resulting in broken code. Work + * around this by avoiding the symbol used in -mstack-protector-guard-symbol= + * entirely in the C code, and use an alias emitted by the linker script + * instead. + */ +#ifdef CONFIG_STACKPROTECTOR +EXPORT_SYMBOL(__ref_stack_chk_guard); +#endif +#endif diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h index 25466c4d2134..3674006e3974 100644 --- a/arch/x86/include/asm/asm-prototypes.h +++ b/arch/x86/include/asm/asm-prototypes.h @@ -20,3 +20,6 @@ extern void cmpxchg8b_emu(void); #endif +#if defined(__GENKSYMS__) && defined(CONFIG_STACKPROTECTOR) +extern unsigned long __ref_stack_chk_guard; +#endif diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index a5f221ea5688..f43bb974fc66 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2089,8 +2089,10 @@ void syscall_init(void) #ifdef CONFIG_STACKPROTECTOR DEFINE_PER_CPU(unsigned long, __stack_chk_guard); +#ifndef CONFIG_SMP EXPORT_PER_CPU_SYMBOL(__stack_chk_guard); #endif +#endif #endif /* CONFIG_X86_64 */ diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index b8c5741d2fb4..feb8102a9ca7 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -491,6 +491,9 @@ SECTIONS . = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE), "kernel image bigger than KERNEL_IMAGE_SIZE"); +/* needed for Clang - see arch/x86/entry/entry.S */ +PROVIDE(__ref_stack_chk_guard = __stack_chk_guard); + #ifdef CONFIG_X86_64 /* * Per-cpu symbols which need to be offset from __per_cpu_load

3 months

3
2
0 0

[PATCH] mm/huge_memory: Fix to make vma_adjust_trans_huge() use find_vma() correctly

by Jeongjun Park

vma_adjust_trans_huge() uses find_vma() to get the VMA, but find_vma() uses the returned pointer without any verification, even though it may return NULL. In this case, NULL pointer dereference may occur, so to prevent this, vma_adjust_trans_huge() should be fix to verify the return value of find_vma(). Cc: <stable(a)vger.kernel.org> Fixes: 685405020b9f ("mm/khugepaged: stop using vma linked list") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- mm/huge_memory.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 5734d5d5060f..db55b8abae2e 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2941,9 +2941,12 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma, */ if (adjust_next > 0) { struct vm_area_struct *next = find_vma(vma->vm_mm, vma->vm_end); - unsigned long nstart = next->vm_start; - nstart += adjust_next; - split_huge_pmd_if_needed(next, nstart); + + if (likely(next)) { + unsigned long nstart = next->vm_start; + nstart += adjust_next; + split_huge_pmd_if_needed(next, nstart); + } } } --

3 months

3
5
0 0

[PATCH] can: dev: can_set_termination(): Allow gpio sleep

by Nicolai Buchwitz

The current implementation of can_set_termination() sets the GPIO in a context which cannot sleep. This is an issue if the GPIO controller can sleep (e.g. since the concerning GPIO expander is connected via SPI or I2C). Thus, if the termination resistor is set (eg. with ip link), a warning splat will be issued in the kernel log. Fix this by setting the termination resistor with gpiod_set_value_cansleep() which instead of gpiod_set_value() allows it to sleep. Cc: stable(a)vger.kernel.org Signed-off-by: Nicolai Buchwitz <nb(a)tipi-net.de> --- drivers/net/can/dev/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c index 6792c14fd7eb..681643ab3780 100644 --- a/drivers/net/can/dev/dev.c +++ b/drivers/net/can/dev/dev.c @@ -468,7 +468,7 @@ static int can_set_termination(struct net_device *ndev, u16 term) else set = 0; - gpiod_set_value(priv->termination_gpio, set); + gpiod_set_value_cansleep(priv->termination_gpio, set); return 0; } -- 2.39.5

3 months

3
4
0 0

tmpfs hang after v6.12-rc6

by Chuck Lever

I've found that NFS access to an exported tmpfs file system hangs indefinitely when the client first performs a GETATTR. The hanging nfsd thread is waiting for the inode lock in shmem_getattr(): task:nfsd state:D stack:0 pid:1775 tgid:1775 ppid:2 flags:0x00004000 Call Trace: <TASK> __schedule+0x770/0x7b0 schedule+0x33/0x50 schedule_preempt_disabled+0x19/0x30 rwsem_down_read_slowpath+0x206/0x230 down_read+0x3f/0x60 shmem_getattr+0x84/0xf0 vfs_getattr_nosec+0x9e/0xc0 vfs_getattr+0x49/0x50 fh_getattr+0x43/0x50 [nfsd] fh_fill_pre_attrs+0x4e/0xd0 [nfsd] nfsd4_open+0x51f/0x910 [nfsd] nfsd4_proc_compound+0x492/0x5d0 [nfsd] nfsd_dispatch+0x117/0x1f0 [nfsd] svc_process_common+0x3b2/0x5e0 [sunrpc] ? __pfx_nfsd_dispatch+0x10/0x10 [nfsd] svc_process+0xcf/0x130 [sunrpc] svc_recv+0x64e/0x750 [sunrpc] ? __wake_up_bit+0x4b/0x60 ? __pfx_nfsd+0x10/0x10 [nfsd] nfsd+0xc6/0xf0 [nfsd] kthread+0xed/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2e/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> I bisected the problem to: d949d1d14fa281ace388b1de978e8f2cd52875cf is the first bad commit commit d949d1d14fa281ace388b1de978e8f2cd52875cf Author: Jeongjun Park <aha310510(a)gmail.com> AuthorDate: Mon Sep 9 21:35:58 2024 +0900 Commit: Andrew Morton <akpm(a)linux-foundation.org> CommitDate: Mon Oct 28 21:40:39 2024 -0700 mm: shmem: fix data-race in shmem_getattr() ... Link: https://lkml.kernel.org/r/20240909123558.70229-1-aha310510@gmail.com Fixes: 44a30220bc0a ("shmem: recalculate file inode when fstat") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> Reported-by: syzbot <syzkaller(a)googlegroup.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> which first appeared in v6.12-rc6, and adds the line that is waiting on the inode lock when my NFS server hangs. I haven't yet found the process that is holding the inode lock for this inode. Because this commit addresses only a KCSAN splat that has been present since v4.3, and does not address a reported behavioral issue, I respectfully request that this commit be reverted immediately so that it does not appear in v6.12 final. Troubleshooting and testing should continue until a fix to the KCSAN issue can be found that does not deadlock NFS exports of tmpfs. -- Chuck Lever

3 months

4
11
0 0

[PATCH 6.6] s390/pkey: Wipe copies of clear-key structures on failure

by Bin Lan

From: Holger Dengler <dengler(a)linux.ibm.com> [ Upstream commit d65d76a44ffe74c73298ada25b0f578680576073 ] Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key. Reviewed-by: Harald Freudenberger <freude(a)linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki(a)linux.ibm.com> Acked-by: Heiko Carstens <hca(a)linux.ibm.com> Signed-off-by: Holger Dengler <dengler(a)linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev(a)linux.ibm.com> [ Resolve minor conflicts to fix CVE-2024-42156 ] Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> --- drivers/s390/crypto/pkey_api.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/s390/crypto/pkey_api.c b/drivers/s390/crypto/pkey_api.c index d2ffdf2491da..70fcb5c40cfe 100644 --- a/drivers/s390/crypto/pkey_api.c +++ b/drivers/s390/crypto/pkey_api.c @@ -1366,9 +1366,7 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, rc = cca_clr2seckey(kcs.cardnr, kcs.domain, kcs.keytype, kcs.clrkey.clrkey, kcs.seckey.seckey); DEBUG_DBG("%s cca_clr2seckey()=%d\n", __func__, rc); - if (rc) - break; - if (copy_to_user(ucs, &kcs, sizeof(kcs))) + if (!rc && copy_to_user(ucs, &kcs, sizeof(kcs))) rc = -EFAULT; memzero_explicit(&kcs, sizeof(kcs)); break; @@ -1401,9 +1399,7 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, kcp.protkey.protkey, &kcp.protkey.len, &kcp.protkey.type); DEBUG_DBG("%s pkey_clr2protkey()=%d\n", __func__, rc); - if (rc) - break; - if (copy_to_user(ucp, &kcp, sizeof(kcp))) + if (!rc && copy_to_user(ucp, &kcp, sizeof(kcp))) rc = -EFAULT; memzero_explicit(&kcp, sizeof(kcp)); break; @@ -1555,11 +1551,14 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, if (copy_from_user(&kcs, ucs, sizeof(kcs))) return -EFAULT; apqns = _copy_apqns_from_user(kcs.apqns, kcs.apqn_entries); - if (IS_ERR(apqns)) + if (IS_ERR(apqns)) { + memzero_explicit(&kcs, sizeof(kcs)); return PTR_ERR(apqns); + } kkey = kzalloc(klen, GFP_KERNEL); if (!kkey) { kfree(apqns); + memzero_explicit(&kcs, sizeof(kcs)); return -ENOMEM; } rc = pkey_clr2seckey2(apqns, kcs.apqn_entries, @@ -1569,15 +1568,18 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, kfree(apqns); if (rc) { kfree(kkey); + memzero_explicit(&kcs, sizeof(kcs)); break; } if (kcs.key) { if (kcs.keylen < klen) { kfree(kkey); + memzero_explicit(&kcs, sizeof(kcs)); return -EINVAL; } if (copy_to_user(kcs.key, kkey, klen)) { kfree(kkey); + memzero_explicit(&kcs, sizeof(kcs)); return -EFAULT; } } -- 2.43.0

3 months

2
1
0 0

[PATCH 6.1] closures: Change BUG_ON() to WARN_ON()

by Bin Lan

From: Kent Overstreet <kent.overstreet(a)linux.dev> [ Upstream commit 339b84ab6b1d66900c27bd999271cb2ae40ce812 ] If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s Signed-off-by: Kent Overstreet <kent.overstreet(a)linux.dev> [ Resolve minor conflicts to fix CVE-2024-42252 ] Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> --- drivers/md/bcache/closure.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c index d8d9394a6beb..18f21d4e9aaa 100644 --- a/drivers/md/bcache/closure.c +++ b/drivers/md/bcache/closure.c @@ -17,10 +17,16 @@ static inline void closure_put_after_sub(struct closure *cl, int flags) { int r = flags & CLOSURE_REMAINING_MASK; - BUG_ON(flags & CLOSURE_GUARD_MASK); - BUG_ON(!r && (flags & ~CLOSURE_DESTRUCTOR)); + if (WARN(flags & CLOSURE_GUARD_MASK, + "closure has guard bits set: %x (%u)", + flags & CLOSURE_GUARD_MASK, (unsigned) __fls(r))) + r &= ~CLOSURE_GUARD_MASK; if (!r) { + WARN(flags & ~CLOSURE_DESTRUCTOR, + "closure ref hit 0 with incorrect flags set: %x (%u)", + flags & ~CLOSURE_DESTRUCTOR, (unsigned) __fls(flags)); + if (cl->fn && !(flags & CLOSURE_DESTRUCTOR)) { atomic_set(&cl->remaining, CLOSURE_REMAINING_INITIALIZER); -- 2.43.0

3 months

3
3
0 0

[PATCH] drm: renesas: rz-du: Increase supported resolutions

by Chris Brandt

The supported resolutions were misrepresented in earlier versions of hardware manuals. Fixes: 768e9e61b3b9 ("drm: renesas: Add RZ/G2L DU Support") Cc: stable(a)vger.kernel.org Signed-off-by: Chris Brandt <chris.brandt(a)renesas.com> --- drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c index b99217b4e05d..90c6269ccd29 100644 --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c @@ -311,11 +311,11 @@ int rzg2l_du_modeset_init(struct rzg2l_du_device *rcdu) dev->mode_config.helper_private = &rzg2l_du_mode_config_helper; /* - * The RZ DU uses the VSP1 for memory access, and is limited - * to frame sizes of 1920x1080. + * The RZ DU was designed to support a frame size of 1920x1200 (landscape) + * or 1200x1920 (portrait). */ dev->mode_config.max_width = 1920; - dev->mode_config.max_height = 1080; + dev->mode_config.max_height = 1920; rcdu->num_crtcs = hweight8(rcdu->info->channels_mask); -- 2.34.1

3 months

3
2
0 0

[PATCH v2] mm/gup: handle NULL pages in unpin_user_pages()

by John Hubbard

The recent addition of "pofs" (pages or folios) handling to gup has a flaw: it assumes that unpin_user_pages() handles NULL pages in the pages** array. That's not the case, as I discovered when I ran on a new configuration on my test machine. Fix this by skipping NULL pages in unpin_user_pages(), just like unpin_folios() already does. Details: when booting on x86 with "numa=fake=2 movablecore=4G" on Linux 6.12, and running this: tools/testing/selftests/mm/gup_longterm ...I get the following crash: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:sanity_check_pinned_pages+0x3a/0x2d0 ... Call Trace: <TASK> ? __die_body+0x66/0xb0 ? page_fault_oops+0x30c/0x3b0 ? do_user_addr_fault+0x6c3/0x720 ? irqentry_enter+0x34/0x60 ? exc_page_fault+0x68/0x100 ? asm_exc_page_fault+0x22/0x30 ? sanity_check_pinned_pages+0x3a/0x2d0 unpin_user_pages+0x24/0xe0 check_and_migrate_movable_pages_or_folios+0x455/0x4b0 __gup_longterm_locked+0x3bf/0x820 ? mmap_read_lock_killable+0x12/0x50 ? __pfx_mmap_read_lock_killable+0x10/0x10 pin_user_pages+0x66/0xa0 gup_test_ioctl+0x358/0xb20 __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 94efde1d1539 ("mm/gup: avoid an unnecessary allocation call for FOLL_LONGTERM cases") Cc: David Hildenbrand <david(a)redhat.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Dongwon Kim <dongwon.kim(a)intel.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Junxiao Chang <junxiao.chang(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: John Hubbard <jhubbard(a)nvidia.com> --- Hi, This is based on v6.12. Changes since v1: Simplified by limiting the change to unpin_user_pages() and the associated sanity_check_pinned_pages(), thanks to David Hildenbrand for pointing out that issue in v1 [1]. [1] https://lore.kernel.org/20241119044923.194853-1-jhubbard@nvidia.com thanks, John Hubbard mm/gup.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/gup.c b/mm/gup.c index ad0c8922dac3..7053f8114e01 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -52,7 +52,12 @@ static inline void sanity_check_pinned_pages(struct page **pages, */ for (; npages; npages--, pages++) { struct page *page = *pages; - struct folio *folio = page_folio(page); + struct folio *folio; + + if (!page) + continue; + + folio = page_folio(page); if (is_zero_page(page) || !folio_test_anon(folio)) @@ -409,6 +414,10 @@ void unpin_user_pages(struct page **pages, unsigned long npages) sanity_check_pinned_pages(pages, npages); for (i = 0; i < npages; i += nr) { + if (!pages[i]) { + nr = 1; + continue; + } folio = gup_folio_next(pages, npages, i, &nr); gup_put_folio(folio, nr, FOLL_PIN); } base-commit: adc218676eef25575469234709c2d87185ca223a -- 2.47.0

3 months

2
1
0 0

[PATCH v2] gpio: exar: set value when external pull-up or pull-down is present

by Sai Kumar Cholleti

Setting GPIO direction = high, sometimes results in GPIO value = 0. If a GPIO is pulled high, the following construction results in the value being 0 when the desired value is 1: $ echo "high" > /sys/class/gpio/gpio336/direction $ cat /sys/class/gpio/gpio336/value 0 Before the GPIO direction is changed from an input to an output, exar_set_value() is called with value = 1, but since the GPIO is an input when exar_set_value() is called, _regmap_update_bits() reads a 1 due to an external pull-up. regmap_set_bits() sets force_write = false, so the value (1) is not written. When the direction is then changed, the GPIO becomes an output with the value of 0 (the hardware default). regmap_write_bits() sets force_write = true, so the value is always written by exar_set_value() and an external pull-up doesn't affect the outcome of setting direction = high. The same can happen when a GPIO is pulled low, but the scenario is a little more complicated. $ echo high > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1 $ echo in > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 0 $ echo low > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1 Fixes: 36fb7218e878 ("gpio: exar: switch to using regmap") Signed-off-by: Sai Kumar Cholleti <skmr537(a)gmail.com> Signed-off-by: Matthew McClain <mmcclain(a)noprivs.com> Cc: <stable(a)vger.kernel.org> --- drivers/gpio/gpio-exar.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c index 5170fe7599cd..dfc7a9ca3e62 100644 --- a/drivers/gpio/gpio-exar.c +++ b/drivers/gpio/gpio-exar.c @@ -99,11 +99,13 @@ static void exar_set_value(struct gpio_chip *chip, unsigned int offset, struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip); unsigned int addr = exar_offset_to_lvl_addr(exar_gpio, offset); unsigned int bit = exar_offset_to_bit(exar_gpio, offset); + unsigned int bit_value = value ? BIT(bit) : 0; - if (value) - regmap_set_bits(exar_gpio->regmap, addr, BIT(bit)); - else - regmap_clear_bits(exar_gpio->regmap, addr, BIT(bit)); + /* + * regmap_write_bits forces value to be written when an external + * pull up/down might otherwise indicate value was already set + */ + regmap_write_bits(exar_gpio->regmap, addr, BIT(bit), bit_value); } static int exar_direction_output(struct gpio_chip *chip, unsigned int offset, -- 2.34.1

3 months

4
8
0 0

[PATCH] ARM: dts: socfpga: sodia: Fix mdio bus probe and PHY ID

by Nobuhiro Iwamatsu

From: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> On SoCFPGA/Sodia board, mdio bus cannot be probed, so the PHY cannot be found and the network device does not work. ``` stmmaceth ff702000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) ``` To probe the mdio bus, add "snps,dwmac-mdio" as compatible string of the mdio bus. Also the PHY ID connected to this board is 4. Therefore, change to 4. Fixes: 8fbc10b995a5 ("net: stmmac: check fwnode for phy device before scanning for phy") Cc: stable(a)vger.kernel.org # 6.3+ Signed-off-by: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> --- arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts index ce0d6514eeb571..e4794ccb8e413f 100644 --- a/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts +++ b/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_sodia.dts @@ -66,8 +66,10 @@ &gmac1 { mdio0 { #address-cells = <1>; #size-cells = <0>; - phy0: ethernet-phy@0 { - reg = <0>; + compatible = "snps,dwmac-mdio"; + + phy0: ethernet-phy@4 { + reg = <4>; rxd0-skew-ps = <0>; rxd1-skew-ps = <0>; rxd2-skew-ps = <0>; -- 2.45.2

3 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror