September 2022 - Linux-stable-mirror

[PATCH] ext4: Fix check for block being out of directory size

by Jan Kara

The check in __ext4_read_dirblock() for block being outside of directory size was wrong because it compared block number against directory size in bytes. Fix it. Fixes: 65f8ea4cd57d ("ext4: check if directory block is within i_size") CVE: CVE-2022-1184 CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 3a31b662f661..bc2e0612ec32 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -126,7 +126,7 @@ static struct buffer_head *__ext4_read_dirblock(struct inode *inode, struct ext4_dir_entry *dirent; int is_dx_block = 0; - if (block >= inode->i_size) { + if (block >= inode->i_size >> inode->i_blkbits) { ext4_error_inode(inode, func, line, block, "Attempting to read directory block (%u) that is past i_size (%llu)", block, inode->i_size); -- 2.35.3

2 years, 2 months

4
3
0 0

[PATCH] random: use tasklet rather than workqueue for mixing fast pool

by Jason A. Donenfeld

Previously, the fast pool was dumped into the main pool peroidically in the fast pool's hard IRQ handler. This worked fine and there weren't problems with it, until RT came around. Since RT converts spinlocks into sleeping locks, problems cropped up. Rather than switching to raw spinlocks, the RT developers preferred we make the transformation from originally doing: do_some_stuff() spin_lock() do_some_other_stuff() spin_unlock() to doing: do_some_stuff() queue_work_on(some_other_stuff_worker) This is an ordinary pattern done all over the kernel. However, Sherry noticed a 10% performance regression in qperf TCP over a 40gbps InfiniBand card. Quoting her message: > MT27500 Family [ConnectX-3] cards: > Infiniband device 'mlx4_0' port 1 status: > default gid: fe80:0000:0000:0000:0010:e000:0178:9eb1 > base lid: 0x6 > sm lid: 0x1 > state: 4: ACTIVE > phys state: 5: LinkUp > rate: 40 Gb/sec (4X QDR) > link_layer: InfiniBand > > Cards are configured with IP addresses on private subnet for IPoIB > performance testing. > Regression identified in this bug is in TCP latency in this stack as reported > by qperf tcp_lat metric: > > We have one system listen as a qperf server: > [root@yourQperfServer ~]# qperf > > Have the other system connect to qperf server as a client (in this > case, it’s X7 server with Mellanox card): > [root@yourQperfClient ~]# numactl -m0 -N0 qperf 20.20.20.101 -v -uu -ub --time 60 --wait_server 20 -oo msg_size:4K:1024K:*2 tcp_lat Rather than incur the scheduling latency from queue_work_on, we can instead switch to a tasklet, which will run on the same core -- exactly what we want -- and happen during context transition without additional scheduling latency, and minimized logic in the enqueuing path. Hopefully this restores performance from prior to the RT changes. Reported-by: Sherry Yang <sherry.yang(a)oracle.com> Suggested-by: Sultan Alsawaf <sultan(a)kerneltoast.com> Fixes: 58340f8e952b ("random: defer fast pool mixing to worker") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/lkml/YyuREcGAXV9828w5@zx2c4.com/ Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- Hi Sherry, I'm not going to commit to this until I receive your `Tested-by:`, so please let me know if this fixes the problem. If not, we'll try something else. Thanks, Jason drivers/char/random.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 520a385c7dab..ad17b36cf977 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -918,13 +918,16 @@ EXPORT_SYMBOL_GPL(unregister_random_vmfork_notifier); #endif struct fast_pool { - struct work_struct mix; + struct tasklet_struct mix; unsigned long pool[4]; unsigned long last; unsigned int count; }; +static void mix_interrupt_randomness(struct tasklet_struct *work); + static DEFINE_PER_CPU(struct fast_pool, irq_randomness) = { + .mix = { .use_callback = true, .callback = mix_interrupt_randomness }, #ifdef CONFIG_64BIT #define FASTMIX_PERM SIPHASH_PERMUTATION .pool = { SIPHASH_CONST_0, SIPHASH_CONST_1, SIPHASH_CONST_2, SIPHASH_CONST_3 } @@ -973,7 +976,7 @@ int __cold random_online_cpu(unsigned int cpu) } #endif -static void mix_interrupt_randomness(struct work_struct *work) +static void mix_interrupt_randomness(struct tasklet_struct *work) { struct fast_pool *fast_pool = container_of(work, struct fast_pool, mix); /* @@ -1027,10 +1030,8 @@ void add_interrupt_randomness(int irq) if (new_count < 1024 && !time_is_before_jiffies(fast_pool->last + HZ)) return; - if (unlikely(!fast_pool->mix.func)) - INIT_WORK(&fast_pool->mix, mix_interrupt_randomness); fast_pool->count |= MIX_INFLIGHT; - queue_work_on(raw_smp_processor_id(), system_highpri_wq, &fast_pool->mix); + tasklet_hi_schedule(&fast_pool->mix); } EXPORT_SYMBOL_GPL(add_interrupt_randomness); -- 2.37.3

2 years, 2 months

3
7
0 0

[PATCH 1/1] io_uring/net: fix fast_iov assignment in io_setup_async_msg()

by Stefan Metzmacher

I hit a very bad problem during my tests of SENDMSG_ZC. BUG(); in first_iovec_segment() triggered very easily. The problem was io_setup_async_msg() in the partial retry case, which seems to happen more often with _ZC. iov_iter_iovec_advance() may change i->iov in order to have i->iov_offset being only relative to the first element. Which means kmsg->msg.msg_iter.iov is no longer the same as kmsg->fast_iov. But this would rewind the copy to be the start of async_msg->fast_iov, which means the internal state of sync_msg->msg.msg_iter is inconsitent. I tested with 5 vectors with length like this 4, 0, 64, 20, 8388608 and got a short writes with: - ret=2675244 min_ret=8388692 => remaining 5713448 sr->done_io=2675244 - ret=-EAGAIN => io_uring_poll_arm - ret=4911225 min_ret=5713448 => remaining 802223 sr->done_io=7586469 - ret=-EAGAIN => io_uring_poll_arm - ret=802223 min_ret=802223 => res=8388692 While this was easily triggered with SENDMSG_ZC (queued for 6.1), it was a potential problem starting with 7ba89d2af17aa879dda30f5d5d3f152e587fc551 in 5.18 for IORING_OP_RECVMSG. And also with 4c3c09439c08b03d9503df0ca4c7619c5842892e in 5.19 for IORING_OP_SENDMSG. However 257e84a5377fbbc336ff563833a8712619acce56 introduced the critical code into io_setup_async_msg() in 5.11. Fixes: 7ba89d2af17aa ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly") Fixes: 257e84a5377fb ("io_uring: refactor sendmsg/recvmsg iov managing") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> --- io_uring/net.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/io_uring/net.c b/io_uring/net.c index 60e392f7f2dc..a81fccd38ae4 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -165,8 +165,10 @@ static int io_setup_async_msg(struct io_kiocb *req, memcpy(async_msg, kmsg, sizeof(*kmsg)); async_msg->msg.msg_name = &async_msg->addr; /* if were using fast_iov, set it to the new one */ - if (!async_msg->free_iov) - async_msg->msg.msg_iter.iov = async_msg->fast_iov; + if (!kmsg->free_iov) { + size_t fast_idx = kmsg->msg.msg_iter.iov - kmsg->fast_iov; + async_msg->msg.msg_iter.iov = &async_msg->fast_iov[fast_idx]; + } return -EAGAIN; } -- 2.34.1

2 years, 2 months

3
2
0 0

[PATCH v1] ksmbd: Fix user namespace mapping

by Mickaël Salaün

A kernel daemon should not rely on the current thread, which is unknown and might be malicious. Before this security fix, ksmbd_override_fsids() didn't correctly override FS UID/GID which means that arbitrary user space threads could trick the kernel to impersonate arbitrary users or groups for file system access checks, leading to file system access bypass. This was found while investigating truncate support for Landlock: https://lore.kernel.org/r/CAKYAXd8fpMJ7guizOjHgxEyyjoUwPsx3jLOPZP=wPYcbhkVX… Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: Hyunchul Lee <hyc.lee(a)gmail.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: Steve French <smfrench(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Mickaël Salaün <mic(a)digikod.net> Link: https://lore.kernel.org/r/20220929100447.108468-1-mic@digikod.net --- fs/ksmbd/smb_common.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ksmbd/smb_common.c b/fs/ksmbd/smb_common.c index 7f8ab14fb8ec..d96da872d70a 100644 --- a/fs/ksmbd/smb_common.c +++ b/fs/ksmbd/smb_common.c @@ -4,6 +4,8 @@ * Copyright (C) 2018 Namjae Jeon <linkinjeon(a)kernel.org> */ +#include <linux/user_namespace.h> + #include "smb_common.h" #include "server.h" #include "misc.h" @@ -625,8 +627,8 @@ int ksmbd_override_fsids(struct ksmbd_work *work) if (!cred) return -ENOMEM; - cred->fsuid = make_kuid(current_user_ns(), uid); - cred->fsgid = make_kgid(current_user_ns(), gid); + cred->fsuid = make_kuid(&init_user_ns, uid); + cred->fsgid = make_kgid(&init_user_ns, gid); gi = groups_alloc(0); if (!gi) { base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff -- 2.37.2

2 years, 2 months

3
4
0 0

setns() affecting other threads in 5.10.132 and 6.0

by David Laight

Sometime after 5.10.105 (5.10.132 and 6.0) there is a change that makes setns(open("/proc/1/ns/net")) in the main process change the behaviour of other process threads. I don't know how much is broken, but the following fails. Create a network namespace (eg "test"). Create a 'bond' interface (eg "test0") in the namespace. Then /proc/net/bonding/test0 only exists inside the namespace. However if you run a program in the "test" namespace that does: - create a thread. - change the main thread to in "init" namespace. - try to open /proc/net/bonding/test0 in the thread. then the open fails. I don't know how much else is affected and haven't tried to bisect (I can't create bonds on my normal test kernel). The test program below shows the problem. Compile and run as: # ip netns exec test strace -f test_prog /proc/net/bonding/test0 The second open by the child should succeed, but fails. I can't see any changes to the bonding code, so I suspect it is something much more fundamental. It might only affect /proc/net, but it might also affect which namespace sockets get created in. IIRC ls -l /proc/n/task/*/ns gives the correct namespaces. David #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <poll.h> #include <pthread.h> #include <sched.h> #define delay(secs) poll(0,0, (secs) * 1000) static void *thread_fn(void *file) { delay(2); open(file, O_RDONLY); delay(5); open(file, O_RDONLY); return NULL; } int main(int argc, char **argv) { pthread_t id; pthread_create(&id, NULL, thread_fn, argv[1]); delay(1); open(argv[1], O_RDONLY); delay(2); setns(open("/proc/1/ns/net", O_RDONLY), 0); delay(1); open(argv[1], O_RDONLY); delay(4); return 0; } - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

2 years, 2 months

4
7
0 0

[tip: x86/urgent] x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant

by tip-bot2 for Borislav Petkov

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: df5b035b5683d6a25f077af889fb88e09827f8bc Gitweb: https://git.kernel.org/tip/df5b035b5683d6a25f077af889fb88e09827f8bc Author: Borislav Petkov <bp(a)suse.de> AuthorDate: Fri, 19 Aug 2022 19:47:44 +02:00 Committer: Borislav Petkov <bp(a)suse.de> CommitterDate: Wed, 28 Sep 2022 18:35:37 +02:00 x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant On a CONFIG_SMP=n kernel, the LLC shared mask is 0, which prevents __cache_amd_cpumap_setup() from doing the L3 masks setup, and more specifically from setting up the shared_cpu_map and shared_cpu_list files in sysfs, leading to lscpu from util-linux getting confused and segfaulting. Add a cpu_llc_shared_mask() UP variant which returns a mask with a single bit set, i.e., for CPU0. Fixes: 2b83809a5e6d ("x86/cpu/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask") Reported-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/1660148115-302-1-git-send-email-ssengar@linux.mic… --- arch/x86/include/asm/smp.h | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 81a0211..a73bced 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -21,16 +21,6 @@ DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id); DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id); DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number); -static inline struct cpumask *cpu_llc_shared_mask(int cpu) -{ - return per_cpu(cpu_llc_shared_map, cpu); -} - -static inline struct cpumask *cpu_l2c_shared_mask(int cpu) -{ - return per_cpu(cpu_l2c_shared_map, cpu); -} - DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid); DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid); DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid); @@ -172,6 +162,16 @@ extern int safe_smp_processor_id(void); # define safe_smp_processor_id() smp_processor_id() #endif +static inline struct cpumask *cpu_llc_shared_mask(int cpu) +{ + return per_cpu(cpu_llc_shared_map, cpu); +} + +static inline struct cpumask *cpu_l2c_shared_mask(int cpu) +{ + return per_cpu(cpu_l2c_shared_map, cpu); +} + #else /* !CONFIG_SMP */ #define wbinvd_on_cpu(cpu) wbinvd() static inline int wbinvd_on_all_cpus(void) @@ -179,6 +179,11 @@ static inline int wbinvd_on_all_cpus(void) wbinvd(); return 0; } + +static inline struct cpumask *cpu_llc_shared_mask(int cpu) +{ + return (struct cpumask *)cpumask_of(0); +} #endif /* CONFIG_SMP */ extern unsigned disabled_cpus;

2 years, 2 months

1
0
0 0

[PATCH] usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video()

by Nathan Chancellor

When building s390 allmodconfig after commit 9b91a6523078 ("usb: gadget: uvc: increase worker prio to WQ_HIGHPRI"), the following error occurs: In file included from ../include/linux/string.h:253, from ../include/linux/bitmap.h:11, from ../include/linux/cpumask.h:12, from ../include/linux/smp.h:13, from ../include/linux/lockdep.h:14, from ../include/linux/rcupdate.h:29, from ../include/linux/rculist.h:11, from ../include/linux/pid.h:5, from ../include/linux/sched.h:14, from ../include/linux/ratelimit.h:6, from ../include/linux/dev_printk.h:16, from ../include/linux/device.h:15, from ../drivers/usb/gadget/function/f_uvc.c:9: In function ‘fortify_memset_chk’, inlined from ‘uvc_register_video’ at ../drivers/usb/gadget/function/f_uvc.c:424:2: ../include/linux/fortify-string.h:301:25: error: call to ‘__write_overflow_field’ declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 301 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This points to the memset() in uvc_register_video(). It is clear that the argument to sizeof() is incorrect, as uvc->vdev (a 'struct video_device') is being zeroed out but the size of uvc->video (a 'struct uvc_video') is being used as the third arugment to memset(). pahole shows that prior to commit 9b91a6523078 ("usb: gadget: uvc: increase worker prio to WQ_HIGHPRI"), 'struct video_device' and 'struct ucv_video' had the same size, meaning that the argument to sizeof() is incorrect semantically but there is no visible issue: $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+" video_device 1400 4 uvc_video 1400 3 After that change, uvc_video becomes slightly larger, meaning that the memset() will overwrite by 8 bytes: $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+" video_device 1400 4 uvc_video 1408 3 Fix the arugment to sizeof() so that there is no overwrite. Cc: stable(a)vger.kernel.org Fixes: e4ce9ed835bc ("usb: gadget: uvc: ensure the vdev is unset") Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/usb/gadget/function/f_uvc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 71669e0e4d00..86bb0098fb66 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -421,7 +421,7 @@ uvc_register_video(struct uvc_device *uvc) int ret; /* TODO reference counting. */ - memset(&uvc->vdev, 0, sizeof(uvc->video)); + memset(&uvc->vdev, 0, sizeof(uvc->vdev)); uvc->vdev.v4l2_dev = &uvc->v4l2_dev; uvc->vdev.v4l2_dev->dev = &cdev->gadget->dev; uvc->vdev.fops = &uvc_v4l2_fops; base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff -- 2.37.3

2 years, 2 months

3
2
0 0

Re: linux-5.15.69 breaks nfs client

by Thorsten Leemhuis

Hi, this is your Linux kernel regression tracker. CCing the regression mailing list, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html Also CCing the stable ml, the NFS maintainers, and the authors of 31b992b3c39b, too. On 22.09.22 23:46, Kurt Garloff wrote: > > a freshly compiled 5.15.69 kernel showed hangs with NFS. > Typically mkdir would end up in a 'D' process state, but I > have seen ls -l hanging as well. > Server is kernel NFS 5.15.69. > > After reverting the last three NFS related commits, > a68a734b19af NFS: Fix WARN_ON due to unionization of nfs_inode.nrequests > 3b97deb4abf5 NFS: Fix another fsync() issue after a server reboot > 31b992b3c39b NFS: Save some space in the inode > > things work normally again. > > As you can see, I suspected 31b992b3c39b ... FWIW, that's e591b298d7ec in mainline. > I know this report is light on details; if nothing like this has been > reported yet, let me know and I'll try to find some time to investigate > further. > > PS: Please keep me on Cc, I'm not subscribed to linux-nfs. I wonder if this is this is a dup of this report: https://lore.kernel.org/all/c5d8485b-0dbc-5192-4dc6-10ef2b86b520@molgen.mpg… In that thread Trond mentioned ``` I believe this is a dependency that was introduced by the back port of commit e591b298d7ec ("NFS: Save some space in the inode") into 5.15.68. So the reason it wasn't seen is because the change is very recent. FYI Greg and Sasha: please also consider pulling 6e176d47160c ("NFSv4: Fixes for nfs4_inode_return_delegation()") into that stable series. ``` Anyway, for the rest of this mail: [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.] Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 31b992b3c39b #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/ Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.

2 years, 2 months

1
1
0 0

Re: nfs_scan_commit: BUG: unable to handle page fault for address: 000000001d473c07

by Trond Myklebust

Hi Paul, On Wed, 2022-09-21 at 13:42 +0200, Paul Menzel wrote: > Dear Linux folks, > > > Moving from Linux 5.10.113 to 5.15.69, starting Mozilla Thunderbird > or > Mozilla Firefox with the home on NFS, both programs get killed, and > Linux 5.15.69 logs: > > ``` > [ 3827.604396] BUG: unable to handle page fault for address: > 000000001d473c07 > [ 3827.611297] #PF: supervisor read access in kernel mode > [ 3827.616452] #PF: error_code(0x0000) - not-present page > [ 3827.621604] PGD 0 P4D 0 > [ 3827.624152] Oops: 0000 [#1] SMP PTI > [ 3827.627657] CPU: 0 PID: 2378 Comm: firefox Not tainted > 5.15.69.mx64.435 #1 > [ 3827.634551] Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, > BIOS 2.20.0 12/09/2021 > [ 3827.642659] RIP: 0010:nfs_scan_commit_list+0x1e/0x100 [nfs] > [ 3827.648256] Code: 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 > 00 > 41 57 41 56 41 55 41 54 55 53 48 83 ec 10 4c 8b 2f 48 89 3c 24 89 4c > 24 > 0c <49> 8b 5d 00 4c 39 ef 0f 84 c3 00 00 00 48 89 f5 49 89 d6 4d 89 > ef > [ 3827.667057] RSP: 0018:ffffc90002097ce0 EFLAGS: 00010282 > [ 3827.672294] RAX: 000000006329dcd6 RBX: ffffc90002097d60 RCX: > 000000007fffffff > [ 3827.679440] RDX: ffffc90002097d60 RSI: ffffc90002097d50 RDI: > ffff8881d7618b38 > [ 3827.686587] RBP: ffffc90002097d50 R08: 0000000000000001 R09: > 0000000000000000 > [ 3827.693734] R10: 0000000000000000 R11: 61c8864680b583eb R12: > 0000000000000000 > [ 3827.700880] R13: 000000001d473c07 R14: 0000000000000001 R15: > 0000000000000000 > [ 3827.708027] FS: 00007fa6141f2780(0000) GS:ffff88881dc00000(0000) > knlGS:0000000000000000 > [ 3827.716131] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3827.721886] CR2: 000000001d473c07 CR3: 000000012dae0006 CR4: > 00000000003706f0 > [ 3827.729034] DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > [ 3827.736180] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: > 0000000000000400 > [ 3827.743328] Call Trace: > [ 3827.745779] <TASK> > [ 3827.747883] nfs_scan_commit+0x76/0xb0 [nfs] > [ 3827.752167] __nfs_commit_inode+0x108/0x180 [nfs] > [ 3827.756886] nfs_wb_all+0x59/0x110 [nfs] > [ 3827.760822] nfs4_inode_return_delegation+0x58/0x90 [nfsv4] > [ 3827.766413] nfs4_proc_remove+0x101/0x110 [nfsv4] > [ 3827.771130] nfs_unlink+0xf5/0x2d0 [nfs] > [ 3827.775065] vfs_unlink+0x10b/0x280 > [ 3827.778563] do_unlinkat+0x19e/0x2c0 > [ 3827.782158] __x64_sys_unlink+0x3e/0x60 > [ 3827.786002] ? __x64_sys_readlink+0x1b/0x30 > [ 3827.790192] do_syscall_64+0x40/0x90 > [ 3827.793779] entry_SYSCALL_64_after_hwframe+0x61/0xcb > [ 3827.798847] RIP: 0033:0x7fa6142e2aa7 > [ 3827.802435] Code: f0 ff ff 73 01 c3 48 8b 0d be 03 0d 00 f7 d8 64 > 89 > 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 57 00 00 00 > 0f > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 03 0d 00 f7 d8 64 89 01 > 48 > [ 3827.821264] RSP: 002b:00007fff37879a08 EFLAGS: 00000202 ORIG_RAX: > 0000000000000057 > [ 3827.828848] RAX: ffffffffffffffda RBX: 0000000080004005 RCX: > 00007fa6142e2aa7 > [ 3827.835997] RDX: 0000000077120e8d RSI: 00007fa614383520 RDI: > 00007fa605425b88 > [ 3827.843145] RBP: 00007fa605425b88 R08: 00007fff37879add R09: > 0000000000000000 > [ 3827.850291] R10: 00007fa614362ae0 R11: 0000000000000202 R12: > 0000000077120e8d > [ 3827.857439] R13: 00007fff37879add R14: 00007fa6141f26c8 R15: > 0000000000000065 > [ 3827.864586] </TASK> > [ 3827.866776] Modules linked in: rpcsec_gss_krb5 nfsv4 nfs 8021q > garp > stp mrp llc amdgpu snd_hda_codec_realtek snd_hda_codec_generic > ledtrig_audio i915 iommu_v2 gpu_sched drm_ttm_helper iosf_mbi ttm > drm_kms_helper x86_pkg_temp_thermal kvm_intel drm kvm > snd_hda_codec_hdmi > intel_gtt i2c_algo_bit fb_sys_fops syscopyarea sysfillrect > snd_hda_intel > input_leds led_class snd_intel_dspcfg sysimgblt e1000e snd_hda_codec > hid_logitech_hidpp snd_hda_core hid_logitech_dj snd_usb_audio > snd_usbmidi_lib snd_hwdep snd_rawmidi snd_pcm snd_timer uvcvideo > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common > snd > wmi_bmof soundcore wmi iTCO_wdt video irqbypass crc32c_intel > iTCO_vendor_support nfsd auth_rpcgss oid_registry nfs_acl lockd grace > sunrpc ip_tables x_tables unix ipv6 autofs4 > [ 3827.935422] CR2: 000000001d473c07 > [ 3827.938745] ---[ end trace d7dc2bc122fe8836 ]--- > ``` > Does cherry-picking commit 6e176d47160c ("NFSv4: Fixes for nfs4_inode_return_delegation()") into 5.15.69 from the upstream kernel tree fix the problem? 8<--------------------------------------------------- From 6e176d47160cec8bcaa28d9aa06926d72d54237c Mon Sep 17 00:00:00 2001 From: Trond Myklebust <trond.myklebust(a)hammerspace.com> Date: Sun, 10 Oct 2021 10:58:12 +0200 Subject: [PATCH] NFSv4: Fixes for nfs4_inode_return_delegation() We mustn't call nfs_wb_all() on anything other than a regular file. Furthermore, we can exit early when we don't hold a delegation. Reported-by: David Wysochanski <dwysocha(a)redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com> --- fs/nfs/delegation.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c index 11118398f495..7c9eb679dbdb 100644 --- a/fs/nfs/delegation.c +++ b/fs/nfs/delegation.c @@ -755,11 +755,13 @@ int nfs4_inode_return_delegation(struct inode *inode) struct nfs_delegation *delegation; delegation = nfs_start_delegation_return(nfsi); - /* Synchronous recall of any application leases */ - break_lease(inode, O_WRONLY | O_RDWR); - nfs_wb_all(inode); - if (delegation != NULL) + if (delegation != NULL) { + /* Synchronous recall of any application leases */ + break_lease(inode, O_WRONLY | O_RDWR); + if (S_ISREG(inode->i_mode)) + nfs_wb_all(inode); return nfs_end_delegation_return(inode, delegation, 1); + } return 0; } -- 2.37.3 -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust(a)hammerspace.com

2 years, 2 months

5
7
0 0

FAILED: patch "[PATCH] perf record: Fix cpu mask bit setting for mixed mmaps" failed to apply to 5.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.19-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>. Possible dependencies: ca76d7d2812b ("perf record: Fix cpu mask bit setting for mixed mmaps") cbd7bfc7fd99 ("tools/perf: Fix out of bound access to cpu mask array") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ca76d7d2812b46124291f99c9b50aaf63a936f23 Mon Sep 17 00:00:00 2001 From: Adrian Hunter <adrian.hunter(a)intel.com> Date: Thu, 15 Sep 2022 15:26:11 +0300 Subject: [PATCH] perf record: Fix cpu mask bit setting for mixed mmaps With mixed per-thread and (system-wide) per-cpu maps, the "any cpu" value -1 must be skipped when setting CPU mask bits. Prior to commit cbd7bfc7fd99acdd ("tools/perf: Fix out of bound access to cpu mask array") the invalid setting went unnoticed, but since then it causes perf record to fail with an error. Example: Before: $ perf record -e intel_pt// --per-thread uname Failed to initialize parallel data streaming masks After: $ perf record -e intel_pt// --per-thread uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.068 MB perf.data ] Fixes: ae4f8ae16a078964 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps") Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Acked-by: Namhyung Kim <namhyung(a)kernel.org> Cc: Athira Rajeev <atrajeev(a)linux.vnet.ibm.com> Cc: Ian Rogers <irogers(a)google.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20220915122612.81738-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index f87ef43eb820..0f711f88894c 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -3371,6 +3371,8 @@ static int record__mmap_cpu_mask_init(struct mmap_cpu_mask *mask, struct perf_cp return 0; perf_cpu_map__for_each_cpu(cpu, idx, cpus) { + if (cpu.cpu == -1) + continue; /* Return ENODEV is input cpu is greater than max cpu */ if ((unsigned long)cpu.cpu > mask->nbits) return -ENODEV;

2 years, 2 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2022