commit 0fe4548663f7dc2c3b549ef54ce9bb6d40a235be Author: Greg Kroah-Hartman Date: Wed Jan 4 11:39:24 2023 +0100 Linux 5.10.162 Link: https://lore.kernel.org/r/20230103081308.548338576@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Allen Pais Signed-off-by: Greg Kroah-Hartman commit 189556b05e1770263c43fa5b4c689e7cd3fa5b4e Author: Jens Axboe Date: Fri Dec 23 07:04:49 2022 -0700 io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups [ Upstream commit 4464853277d0ccdb9914608dd1332f0fa2f9846f ] Pass in EPOLL_URING_WAKE when signaling eventfd or doing poll related wakups, so that we can check for a circular event dependency between eventfd and epoll. If this flag is set when our wakeup handlers are called, then we know we have a dependency that needs to terminate multishot requests. eventfd and epoll are the only such possible dependencies. Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4ef66581d7fdbd9bfe0b399c1a2479f8ea5cfdf0 Author: Jens Axboe Date: Sun Nov 20 10:13:44 2022 -0700 eventfd: provide a eventfd_signal_mask() helper [ Upstream commit 03e02acda8e267a8183e1e0ed289ff1ef9cd7ed8 ] This is identical to eventfd_signal(), but it allows the caller to pass in a mask to be used for the poll wakeup key. The use case is avoiding repeated multishot triggers if we have a dependency between eventfd and io_uring. If we setup an eventfd context and register that as the io_uring eventfd, and at the same time queue a multishot poll request for the eventfd context, then any CQE posted will repeatedly trigger the multishot request until it terminates when the CQ ring overflows. In preparation for io_uring detecting this circular dependency, add the mentioned helper so that io_uring can pass in EPOLL_URING as part of the poll wakeup key. Cc: stable@vger.kernel.org # 6.0 [axboe: fold in !CONFIG_EVENTFD fix from Zhang Qilong] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2f093775022b45253b0d8df0e7296e7bc0d13a7b Author: Jens Axboe Date: Sun Nov 20 10:10:53 2022 -0700 eventpoll: add EPOLL_URING_WAKE poll wakeup flag [ Upstream commit caf1aeaffc3b09649a56769e559333ae2c4f1802 ] We can have dependencies between epoll and io_uring. Consider an epoll context, identified by the epfd file descriptor, and an io_uring file descriptor identified by iofd. If we add iofd to the epfd context, and arm a multishot poll request for epfd with iofd, then the multishot poll request will repeatedly trigger and generate events until terminated by CQ ring overflow. This isn't a desired behavior. Add EPOLL_URING so that io_uring can pass it in as part of the poll wakeup key, and io_uring can check for that to detect a potential recursive invocation. Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b76c5373f084c802964e751efb825934a9bbbbec Author: Jens Axboe Date: Mon Feb 15 13:42:42 2021 -0700 Revert "proc: don't allow async path resolution of /proc/self components" [ Upstream commit 9e8d9e829c2142cf1d7756e9ed2e0b4c7569d84c ] This reverts commit 8d4c3e76e3be11a64df95ddee52e99092d42fc19. No longer needed, as the io-wq worker threads have the right identity. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 87cb08dc6b4f42a491e582d3ee79c30893681193 Author: Jens Axboe Date: Mon Feb 15 13:42:18 2021 -0700 Revert "proc: don't allow async path resolution of /proc/thread-self components" [ Upstream commit 2587890b5e2892dfecaa5e5126bdac8076a4e6f7 ] This reverts commit 0d4370cfe36b7f1719123b621a4ec4d9c7a25f89. No longer needed, as the io-wq worker threads have the right identity. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a3025359ffa707b484b23f4df37425f36e6955fd Author: Jens Axboe Date: Wed Feb 17 10:14:21 2021 -0700 net: remove cmsg restriction from io_uring based send/recvmsg calls [ Upstream commit e54937963fa249595824439dc839c948188dea83 ] No need to restrict these anymore, as the worker threads are direct clones of the original task. Hence we know for a fact that we can support anything that the regular task can. Since the only user of proto_ops->flags was to flag PROTO_CMSG_DATA_ONLY, kill the member and the flag definition too. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6ef2b4728a00c98cc1163212443e39d79a4c2c94 Author: Jens Axboe Date: Tue Jan 5 11:32:43 2021 -0700 task_work: unconditionally run task_work from get_signal() [ Upstream commit 35d0b389f3b23439ad15b610d6e43fc72fc75779 ] Song reported a boot regression in a kvm image with 5.11-rc, and bisected it down to the below patch. Debugging this issue, turns out that the boot stalled when a task is waiting on a pipe being released. As we no longer run task_work from get_signal() unless it's queued with TWA_SIGNAL, the task goes idle without running the task_work. This prevents ->release() from being called on the pipe, which another boot task is waiting on. For now, re-instate the unconditional task_work run from get_signal(). For 5.12, we'll collapse TWA_RESUME and TWA_SIGNAL, as it no longer makes sense to have a distinction between the two. This will turn task_work notification into a simple boolean, whether to notify or not. Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") Reported-by: Song Liu Tested-by: John Stultz Tested-by: Douglas Anderson Tested-by: Sedat Dilek # LLVM/Clang version 11.0.1 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c91ab04781f9e46c1a2143bd1ba8fc1f1aff6ebc Author: Jens Axboe Date: Fri Oct 9 16:03:01 2020 -0600 signal: kill JOBCTL_TASK_WORK [ Upstream commit 98b89b649fce39dacb9dc036d6d0fdb8caff73f7 ] It's no longer used, get rid of it. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 788d0824269bef539fe31a785b1517882eafed93 Author: Jens Axboe Date: Thu Dec 22 14:30:11 2022 -0700 io_uring: import 5.15-stable io_uring No upstream commit exists. This imports the io_uring codebase from 5.15.85, wholesale. Changes from that code base: - Drop IOCB_ALLOC_CACHE, we don't have that in 5.10. - Drop MKDIRAT/SYMLINKAT/LINKAT. Would require further VFS backports, and we don't support these in 5.10 to begin with. - sock_from_file() old style calling convention. - Use compat_get_bitmap() only for CONFIG_COMPAT=y Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ed3005032993da7a3fe2e6095436e0bc2e83d011 Author: Jens Axboe Date: Thu Apr 1 19:53:29 2021 -0600 task_work: add helper for more targeted task_work canceling [ Upstream commit c7aab1a7c52b82d9afd7e03c398eb03dc2aa0507 ] The only exported helper we have right now is task_work_cancel(), which cancels any task_work from a given task where func matches the queued work item. This is a bit too coarse for some use cases. Add a task_work_cancel_match() that allows to more specifically target individual work items outside of purely the callback function used. task_work_cancel() can be trivially implemented on top of that, hence do so. Reviewed-by: Oleg Nesterov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 831cb78a2a5e86fe705ef4e3095c7cbc587c6a57 Author: Jens Axboe Date: Fri Mar 26 08:57:10 2021 -0600 kernel: don't call do_exit() for PF_IO_WORKER threads [ Upstream commit 10442994ba195efef6fdcc0c3699e4633cb5161b ] Right now we're never calling get_signal() from PF_IO_WORKER threads, but in preparation for doing so, don't handle a fatal signal for them. The workers have state they need to cleanup when exiting, so just return instead of calling do_exit() on their behalf. The threads themselves will detect a fatal signal and do proper shutdown. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9ded44b69c711455dbbddf6ec39b77ac41e4eed7 Author: Jens Axboe Date: Fri Mar 26 09:05:22 2021 -0600 kernel: stop masking signals in create_io_thread() [ Upstream commit b16b3855d89fba640996fefdd3a113c0aa0e380d ] This is racy - move the blocking into when the task is created and we're marking it as PF_IO_WORKER anyway. The IO threads are now prepared to handle signals like SIGSTOP as well, so clear that from the mask to allow proper stopping of IO threads. Acked-by: "Eric W. Biederman" Reported-by: Oleg Nesterov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f0a5f0dc0131c6483908601f6e4907befb609c97 Author: Stefan Metzmacher Date: Wed May 5 13:03:10 2021 +0200 x86/process: setup io_threads more like normal user space threads [ Upstream commit 50b7b6f29de3e18e9d6c09641256a0296361cfee ] As io_threads are fully set up USER threads it's clearer to separate the code path from the KTHREAD logic. The only remaining difference to user space threads is that io_threads never return to user space again. Instead they loop within the given worker function. The fact that they never return to user space means they don't have an user space thread stack. In order to indicate that to tools like gdb we reset the stack and instruction pointers to 0. This allows gdb attach to user space processes using io-uring, which like means that they have io_threads, without printing worrying message like this: warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386 warning: Architecture rejected target-supplied description The output will be something like this: (gdb) info threads Id Target Id Frame * 1 LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 2 LWP 4864 "iou-mgr-4863" 0x0000000000000000 in ?? () 3 LWP 4865 "iou-wrk-4863" 0x0000000000000000 in ?? () (gdb) thread 3 [Switching to thread 3 (LWP 4865)] #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x0 Fixes: 4727dc20e042 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Link: https://lore.kernel.org/io-uring/044d0bad-6888-a211-e1d3-159a4aeed52d@polymtl.ca/T/#m1bbf5727e3d4e839603f6ec7ed79c7eebfba6267 Signed-off-by: Stefan Metzmacher cc: Linus Torvalds cc: Jens Axboe cc: Andy Lutomirski cc: linux-kernel@vger.kernel.org cc: io-uring@vger.kernel.org cc: x86@kernel.org Link: https://lore.kernel.org/r/20210505110310.237537-1-metze@samba.org Reviewed-by: Thomas Gleixner Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dd26e2cec74f88cb7910deec77897d04ade299bd Author: Jens Axboe Date: Tue Feb 23 11:57:20 2021 -0700 arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread() [ Upstream commit 0100e6bbdbb79404e56939313662b42737026574 ] In the arch addition of PF_IO_WORKER, I missed parisc and powerpc for some reason. Fix that up, ensuring they handle PF_IO_WORKER like they do PF_KTHREAD in copy_thread(). Reported-by: Bruno Goncalves Fixes: 4727dc20e042 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 320c8057eceb18c5d836fcbe0ffb0035fcfe28ff Author: Jens Axboe Date: Wed Feb 17 08:48:00 2021 -0700 arch: setup PF_IO_WORKER threads like PF_KTHREAD [ Upstream commit 4727dc20e0422211a0e0c72b1ace4ed6096df8a6 ] PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the sense that we don't assign ->set_child_tid with our own structure. Just ensure that every arch sets up the PF_IO_WORKER threads like kthreads in the arch implementation of copy_thread(). Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 000de389ad7b8094bcf714ee27e2362eb5054a1a Author: Seth Forshee Date: Wed May 4 13:08:40 2022 -0500 entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set [ Upstream commit 3e684903a8574ffc9475fdf13c4780a7adb506ad ] A livepatch transition may stall indefinitely when a kvm vCPU is heavily loaded. To the host, the vCPU task is a user thread which is spending a very long time in the ioctl(KVM_RUN) syscall. During livepatch transition, set_notify_signal() will be called on such tasks to interrupt the syscall so that the task can be transitioned. This interrupts guest execution, but when xfer_to_guest_mode_work() sees that TIF_NOTIFY_SIGNAL is set but not TIF_SIGPENDING it concludes that an exit to user mode is unnecessary, and guest execution is resumed without transitioning the task for the livepatch. This handling of TIF_NOTIFY_SIGNAL is incorrect, as set_notify_signal() is expected to break tasks out of interruptible kernel loops and cause them to return to userspace. Change xfer_to_guest_mode_work() to handle TIF_NOTIFY_SIGNAL the same as TIF_SIGPENDING, signaling to the vCPU run loop that an exit to userpsace is needed. Any pending task_work will be run when get_signal() is called from exit_to_user_mode_loop(), so there is no longer any need to run task work from xfer_to_guest_mode_work(). Suggested-by: "Eric W. Biederman" Cc: Petr Mladek Signed-off-by: Seth Forshee Message-Id: <20220504180840.2907296-1-sforshee@digitalocean.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0f735cf52bd0b2aaca865e3d2e3dc276479e41ba Author: Jens Axboe Date: Mon Mar 22 09:39:12 2021 -0600 kernel: allow fork with TIF_NOTIFY_SIGNAL pending [ Upstream commit 66ae0d1e2d9fe6ec70e73fcfdcf4b390e271c1ac ] fork() fails if signal_pending() is true, but there are two conditions that can lead to that: 1) An actual signal is pending. We want fork to fail for that one, like we always have. 2) TIF_NOTIFY_SIGNAL is pending, because the task has pending task_work. We don't need to make it fail for that case. Allow fork() to proceed if just task_work is pending, by changing the signal_pending() check to task_sigpending(). Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4b4d2c79921a8327e9e853dc93c06b27edb3a859 Author: Eric W. Biederman Date: Thu Jun 10 15:11:11 2021 -0500 coredump: Limit what can interrupt coredumps [ Upstream commit 06af8679449d4ed282df13191fc52d5ba28ec536 ] Olivier Langlois has been struggling with coredumps being incompletely written in processes using io_uring. Olivier Langlois writes: > io_uring is a big user of task_work and any event that io_uring made a > task waiting for that occurs during the core dump generation will > generate a TIF_NOTIFY_SIGNAL. > > Here are the detailed steps of the problem: > 1. io_uring calls vfs_poll() to install a task to a file wait queue > with io_async_wake() as the wakeup function cb from io_arm_poll_handler() > 2. wakeup function ends up calling task_work_add() with TWA_SIGNAL > 3. task_work_add() sets the TIF_NOTIFY_SIGNAL bit by calling > set_notify_signal() The coredump code deliberately supports being interrupted by SIGKILL, and depends upon prepare_signal to filter out all other signals. Now that signal_pending includes wake ups for TIF_NOTIFY_SIGNAL this hack in dump_emitted by the coredump code no longer works. Make the coredump code more robust by explicitly testing for all of the wakeup conditions the coredump code supports. This prevents new wakeup conditions from breaking the coredump code, as well as fixing the current issue. The filesystem code that the coredump code uses already limits itself to only aborting on fatal_signal_pending. So it should not develop surprising wake-up reasons either. v2: Don't remove the now unnecessary code in prepare_signal. Cc: stable@vger.kernel.org Fixes: 12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL") Reported-by: Olivier Langlois Signed-off-by: "Eric W. Biederman" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 90a2c3821bbfe8435bde901953871576a1bf8c6d Author: Jens Axboe Date: Fri Oct 9 16:04:39 2020 -0600 kernel: remove checking for TIF_NOTIFY_SIGNAL [ Upstream commit e296dc4996b8094ccde45d19090d804c4103513e ] It's available everywhere now, no need to check or add dummy defines. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 61bdeb142e8f7550826373295cb35b3571d70f62 Author: Jens Axboe Date: Fri Oct 9 16:01:33 2020 -0600 task_work: remove legacy TWA_SIGNAL path [ Upstream commit 03941ccfda161c2680147fa5ab92aead2a79cac1 ] All archs now support TIF_NOTIFY_SIGNAL. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6e2bce21acb4f0c35521e68d74e4317fd6afd97d Author: Al Viro Date: Sat Sep 18 18:08:56 2021 -0400 alpha: fix TIF_NOTIFY_SIGNAL handling [ Upstream commit e2c7554cc6d85f95e3c6635f270ec839ab9fe05e ] it needs to be added to _TIF_WORK_MASK, or we might not reach do_work_pending() in the first place... Fixes: 5a9a8897c253a "alpha: add support for TIF_NOTIFY_SIGNAL" Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit db911277a2b38b4ef98c7192728d5f4cba7863fe Author: Vineet Gupta Date: Wed Jan 6 12:34:36 2021 -0800 ARC: unbork 5.11 bootup: fix snafu in _TIF_NOTIFY_SIGNAL handling [ Upstream commit bb12433bf56e76789c6b08b36c546f745a6aa6e1 ] Linux 5.11.rcX was failing to boot on ARC HSDK board. Turns out we have a couple of issues, this being the first one, and I'm to blame as I didn't pay attention during review. TIF_NOTIFY_SIGNAL support requires checking multiple TIF_* bits in kernel return code path. Old code only needed to check a single bit so BBIT0 worked. New code needs to check multiple bits so AND instruction. So needs to use bit mask variant _TIF_SIGPENDING Cc: Jens Axboe Fixes: 53855e12588743ea128 ("arc: add support for TIF_NOTIFY_SIGNAL") Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/34 Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit a1240cc413ebb3ec15ee156d3f18f2d5bf1dfe1f Author: Jens Axboe Date: Tue Mar 2 17:22:11 2021 -0700 ia64: don't call handle_signal() unless there's actually a signal queued [ Upstream commit f5f4fc4649ae542b1a25670b17aaf3cbb6187acc ] Sergei and John both reported that ia64 failed to boot in 5.11, and it was related to signals. Turns out the ia64 signal handling is a bit odd, it doesn't check the return value of get_signal() for whether there's a signal to deliver or not. With the introduction of TIF_NOTIFY_SIGNAL, then task_work could trigger it. Fix it by only calling handle_signal() if we actually have a real signal to deliver. This brings it in line with all other archs, too. Fixes: b269c229b0e8 ("ia64: add support for TIF_NOTIFY_SIGNAL") Reported-by: Sergei Trofimovich Reported-by: John Paul Adrian Glaubitz Tested-by: Sergei Trofimovich Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e1402ba4df2025d66b81a8c215e452b95d1796d8 Author: Jens Axboe Date: Fri Oct 9 15:44:37 2020 -0600 sparc: add support for TIF_NOTIFY_SIGNAL [ Upstream commit f50a7052f5e70ee7a6a5e2ed08660994dc3df2a5 ] Wire up TIF_NOTIFY_SIGNAL handling for sparc. Cc: sparclinux@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 78a53ff02656da3c1e6a3e11e30ab23cf4bcb0f7 Author: Jens Axboe Date: Fri Oct 9 14:29:17 2020 -0600 riscv: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 24a31b81e38309b1604f24520110aae1f83f3cbf ] Wire up TIF_NOTIFY_SIGNAL handling for riscv. Cc: linux-riscv@lists.infradead.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 57e833a0a03de1b1d1cfe0db2f9620b50df47502 Author: Jens Axboe Date: Fri Oct 9 15:18:43 2020 -0600 nds32: add support for TIF_NOTIFY_SIGNAL [ Upstream commit b13e8bf615fe26fb6a6dfe1b5a1c65e1624dfee2 ] Wire up TIF_NOTIFY_SIGNAL handling for nds32. Cc: Nick Hu Cc: Greentime Hu Cc: Vincent Chen Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 751fedb9ba5d4af62196d9b3014d4e62945c6e3f Author: Jens Axboe Date: Fri Oct 9 14:49:43 2020 -0600 ia64: add support for TIF_NOTIFY_SIGNAL [ Upstream commit b269c229b0e89aedb7943c06673b56b6052cf5e5 ] Wire up TIF_NOTIFY_SIGNAL handling for ia64. Cc: linux-ia64@vger.kernel.org [axboe: added fixes from Mike Rapoport ] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 48e9e35d33d66519d12deea401487ea705deb596 Author: Jens Axboe Date: Fri Oct 9 14:42:33 2020 -0600 h8300: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 2f9799ad0111ee742ccc02dd2ea2c87646746fc1 ] Wire up TIF_NOTIFY_SIGNAL handling for h8300. Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c82617d9decc3c5af2ab2c66055701f7fbd944f6 Author: Jens Axboe Date: Fri Oct 9 14:35:34 2020 -0600 c6x: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 6d665a4d8b4264def0fbb72da3a500d9904ffe3e ] Wire up TIF_NOTIFY_SIGNAL handling for c6x. Cc: linux-c6x-dev@linux-c6x.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 30b78a17ac8f21751426edbe72fabfc1d825e9a0 Author: Jens Axboe Date: Thu Oct 8 09:11:42 2020 -0600 alpha: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 5a9a8897c253a075805401d38d987ec1ac1824b6 ] Wire up TIF_NOTIFY_SIGNAL handling for alpha. Cc: linux-alpha@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bf0b619593cd5560c55b10dbf290e6e148d1596c Author: Jens Axboe Date: Fri Oct 9 15:56:07 2020 -0600 xtensa: add support for TIF_NOTIFY_SIGNAL [ Upstream commit bec58f40d6c5372d812c93cc3947f3bc97440e57 ] Wire up TIF_NOTIFY_SIGNAL handling for xtensa. Thanks to Max Filippov for making the asm correct. Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1bee9dbbcabbb77617fb257f964628b50ba2529c Author: Jens Axboe Date: Fri Oct 9 16:00:49 2020 -0600 arm: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 32d59773da38cd83e497a70eb9754d4bbae3aeae ] Wire up TIF_NOTIFY_SIGNAL handling for arm. Cc: linux-arm-kernel@lists.infradead.org Acked-by: Russell King Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 02d383a59cbf8b7292947895604a2f9103f4f862 Author: Jens Axboe Date: Fri Oct 9 15:13:57 2020 -0600 microblaze: add support for TIF_NOTIFY_SIGNAL [ Upstream commit f4ea089e429e0d366cd1a34a2cbe3c7b13d98d75 ] Wire up TIF_NOTIFY_SIGNAL handling for microblaze. Acked-by: Michal Simek Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 19f3e328b4c6202198f27a3b899811d4a118333f Author: Jens Axboe Date: Fri Oct 9 14:45:22 2020 -0600 hexagon: add support for TIF_NOTIFY_SIGNAL [ Upstream commit aeec8193578a71d0aee21218351849d38121ce90 ] Wire up TIF_NOTIFY_SIGNAL handling for hexagon. Cc: linux-hexagon@vger.kernel.org Acked-by: Brian Cain Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c2037d61dec2b07add549cb7e762702076279b2b Author: Jens Axboe Date: Fri Oct 9 14:39:00 2020 -0600 csky: add support for TIF_NOTIFY_SIGNAL [ Upstream commit f3924d763c8af4c5d441b666c01f4de03ac9449e ] Wire up TIF_NOTIFY_SIGNAL handling for csky. Cc: linux-csky@vger.kernel.org Acked-by: Guo Ren Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 12284aec880fc9f06d98d2fee28982c030cf99cf Author: Jens Axboe Date: Fri Oct 9 15:24:46 2020 -0600 openrisc: add support for TIF_NOTIFY_SIGNAL [ Upstream commit e181c0aa2e532af2b17128fbde699f8578cc0562 ] Wire up TIF_NOTIFY_SIGNAL handling for openrisc. Cc: openrisc@lists.librecores.org Acked-by: Stafford Horne Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3fde31e9626247e189dca71fe4723b8c722a676c Author: Jens Axboe Date: Fri Oct 9 15:36:35 2020 -0600 sh: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 6d3a273355e3c8471ddf9e8ce9a7cc4472bf1ccc ] Wire up TIF_NOTIFY_SIGNAL handling for sh. Cc: linux-sh@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dc808ffd9778aa013c792bb2ed369b84e346b67f Author: Jens Axboe Date: Fri Oct 9 15:47:28 2020 -0600 um: add support for TIF_NOTIFY_SIGNAL [ Upstream commit a5b3cd32ff238b87e94d47b927aff117e22d13c0 ] Wire up TIF_NOTIFY_SIGNAL handling for um. Cc: linux-um@lists.infradead.org Acked-By: Anton Ivanov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0aef2ec0639459444f90fe59751ec74b60af4e62 Author: Jens Axboe Date: Fri Oct 9 15:34:12 2020 -0600 s390: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 75309018a24ddfb930c51bad8f4070b9bc2c923b ] Wire up TIF_NOTIFY_SIGNAL handling for s390. Cc: linux-s390@vger.kernel.org Acked-by: Heiko Carstens Acked-by: Sven Schnelle Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8ca2e5709922dc8c68323fdeeee099bb89a7c080 Author: Jens Axboe Date: Fri Oct 9 15:16:02 2020 -0600 mips: add support for TIF_NOTIFY_SIGNAL [ Upstream commit f45c184bce15f4a314c0210519bc3b4aab408838 ] Wire up TIF_NOTIFY_SIGNAL handling for mips. Cc: linux-mips@vger.kernel.org Acked-By: Thomas Bogendoerfer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit abab3d4444b5f4732d741f45feb954fabb78af7f Author: Jens Axboe Date: Thu Oct 22 20:11:56 2020 -0600 powerpc: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 900f0713fdd730fab0f0bfa4a8ca4db2a8985bbe ] Wire up TIF_NOTIFY_SIGNAL handling for powerpc. Cc: linuxppc-dev@lists.ozlabs.org Acked-by: Michael Ellerman Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 45b365bc6c1b57da984c70cae0c6c783ec094399 Author: Jens Axboe Date: Fri Oct 9 15:27:02 2020 -0600 parisc: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 18cb3281285d2190c0605d2e53543802319bd1a1 ] Wire up TIF_NOTIFY_SIGNAL handling for parisc. Cc: linux-parisc@vger.kernel.org Acked-by: Helge Deller Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cf3c6486731979a78851428d9e45e6f943b5fa92 Author: Jens Axboe Date: Fri Oct 9 15:21:21 2020 -0600 nios32: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 42020064274c235d720d9c4b7d9a678b133e59cf ] Wire up TIF_NOTIFY_SIGNAL handling for nios32. Cc: Ley Foon Tan Acked-by: Ley Foon Tan Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fe137f46d41f90e1a36134e7876db897a25b7926 Author: Jens Axboe Date: Fri Oct 9 15:10:55 2020 -0600 m68k: add support for TIF_NOTIFY_SIGNAL [ Upstream commit e660653cd9f2df470d156c249631f68b9dee51ee ] Wire up TIF_NOTIFY_SIGNAL handling for m68k. Cc: linux-m68k@lists.linux-m68k.org Acked-by: Geert Uytterhoeven Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 79a9991e87fe61ff2a8b5ac8c112b3ce3544cb53 Author: Jens Axboe Date: Thu Oct 22 20:09:23 2020 -0600 arm64: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 192caabd4dd92c98d23ed4334d7596af05af2fb4 ] Wire up TIF_NOTIFY_SIGNAL handling for arm64. Cc: linux-arm-kernel@lists.infradead.org Acked-by: Will Deacon Acked-by: Catalin Marinas Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2dbb0354517b1ebef40890d05ce8362e99b86179 Author: Jens Axboe Date: Mon Oct 12 07:15:37 2020 -0600 arc: add support for TIF_NOTIFY_SIGNAL [ Upstream commit 53855e12588743ea128ee31f913d1c6e2f1d32c8 ] Wire up TIF_NOTIFY_SIGNAL handling for arc. Cc: linux-snps-arc@lists.infradead.org Acked-by: Vineet Gupta Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4b1dcf8ec9b2f11b57f1ff5dcaa1f8575c7dacb5 Author: Jens Axboe Date: Mon Oct 26 14:32:29 2020 -0600 x86: Wire up TIF_NOTIFY_SIGNAL [ Upstream commit c8d5ed67936fddbe2ae845fc80397718006322d7 ] The generic entry code has support for TIF_NOTIFY_SIGNAL already. Just provide the TIF bit. [ tglx: Adopted to other TIF changes in x86 ] Signed-off-by: Jens Axboe Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20201026203230.386348-4-axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman commit eb42e7b3043167d21f90204df75fa21b6d4af3ff Author: Jens Axboe Date: Mon Oct 26 14:32:30 2020 -0600 task_work: Use TIF_NOTIFY_SIGNAL if available [ Upstream commit 114518eb6430b832d2f9f5a008043b913ccf0e24 ] If the arch supports TIF_NOTIFY_SIGNAL, then use that for TWA_SIGNAL as it's more efficient than using the signal delivery method. This is especially true on threaded applications, where ->sighand is shared across threads, but it's also lighter weight on non-shared cases. io_uring is a heavy consumer of TWA_SIGNAL based task_work. A test with threads shows a nice improvement running an io_uring based echo server. stock kernel: 0.01% <= 0.1 milliseconds 95.86% <= 0.2 milliseconds 98.27% <= 0.3 milliseconds 99.71% <= 0.4 milliseconds 100.00% <= 0.5 milliseconds 100.00% <= 0.6 milliseconds 100.00% <= 0.7 milliseconds 100.00% <= 0.8 milliseconds 100.00% <= 0.9 milliseconds 100.00% <= 1.0 milliseconds 100.00% <= 1.1 milliseconds 100.00% <= 2 milliseconds 100.00% <= 3 milliseconds 100.00% <= 3 milliseconds 1378930.00 requests per second ~1600% CPU 1.38M requests/second, and all 16 CPUs are maxed out. patched kernel: 0.01% <= 0.1 milliseconds 98.24% <= 0.2 milliseconds 99.47% <= 0.3 milliseconds 99.99% <= 0.4 milliseconds 100.00% <= 0.5 milliseconds 100.00% <= 0.6 milliseconds 100.00% <= 0.7 milliseconds 100.00% <= 0.8 milliseconds 100.00% <= 0.9 milliseconds 100.00% <= 1.2 milliseconds 1666111.38 requests per second ~1450% CPU 1.67M requests/second, and we're no longer just hammering on the sighand lock. The original reporter states: "For 5.7.15 my benchmark achieves 1.6M qps and system cpu is at ~80%. for 5.7.16 or later it achieves only 1M qps and the system cpu is is at ~100%" with the only difference there being that TWA_SIGNAL is used unconditionally in 5.7.16, since it's required to be able to handle the inability to run task_work if the application is waiting in the kernel already on an event that needs task_work run to be satisfied. Also see commit 0ba9c9edcd15. Reported-by: Roman Gershman Signed-off-by: Jens Axboe Signed-off-by: Thomas Gleixner Reviewed-by: Oleg Nesterov Link: https://lore.kernel.org/r/20201026203230.386348-5-axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman commit 3c295bd2ddaecf3509458c86bf7ba610042f3609 Author: Jens Axboe Date: Mon Oct 26 14:32:28 2020 -0600 entry: Add support for TIF_NOTIFY_SIGNAL [ Upstream commit 12db8b690010ccfadf9d0b49a1e1798e47dbbe1a ] Add TIF_NOTIFY_SIGNAL handling in the generic entry code, which if set, will return true if signal_pending() is used in a wait loop. That causes an exit of the loop so that notify_signal tracehooks can be run. If the wait loop is currently inside a system call, the system call is restarted once task_work has been processed. In preparation for only having arch_do_signal() handle syscall restarts if _TIF_SIGPENDING isn't set, rename it to arch_do_signal_or_restart(). Pass in a boolean that tells the architecture specific signal handler if it should attempt to get a signal, or just process a potential syscall restart. For !CONFIG_GENERIC_ENTRY archs, add the TIF_NOTIFY_SIGNAL handling to get_signal(). This is done to minimize the needed architecture changes to support this feature. Signed-off-by: Jens Axboe Signed-off-by: Thomas Gleixner Reviewed-by: Oleg Nesterov Link: https://lore.kernel.org/r/20201026203230.386348-3-axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman commit d2136fc145be417e851dfe50703fac2af6aabe46 Author: Jens Axboe Date: Tue Jan 19 15:41:52 2021 -0700 fs: provide locked helper variant of close_fd_get_file() [ Upstream commit 53dec2ea74f2ef360e8455439be96a780baa6097 ] Assumes current->files->file_lock is already held on invocation. Helps the caller check the file before removing the fd, if it needs to. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 57b20530363d127ab6a82e336275769258eb5f37 Author: Eric W. Biederman Date: Fri Nov 20 17:14:40 2020 -0600 file: Rename __close_fd_get_file close_fd_get_file [ Upstream commit 9fe83c43e71cdb8e5b9520bcb98706a2b3c680c8 ] The function close_fd_get_file is explicitly a variant of __close_fd[1]. Now that __close_fd has been renamed close_fd, rename close_fd_get_file to be consistent with close_fd. When __alloc_fd, __close_fd and __fd_install were introduced the double underscore indicated that the function took a struct files_struct parameter. The function __close_fd_get_file never has so the naming has always been inconsistent. This just cleans things up so there are not any lingering mentions or references __close_fd left in the code. [1] 80cd795630d6 ("binder: fix use-after-free due to ksys_close() during fdget()") Link: https://lkml.kernel.org/r/20201120231441.29911-23-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 214f80e25176eb4d756bc9fe528ef7bf23d2f9a1 Author: Jens Axboe Date: Sat Sep 26 17:20:17 2020 -0600 fs: make do_renameat2() take struct filename [ Upstream commit e886663cfd029b64a1d8da7efae7014526d884e9 ] Pass in the struct filename pointers instead of the user string, and update the three callers to do the same. This behaves like do_unlinkat(), which also takes a filename struct and puts it when it is done. Converting callers is then trivial. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 52cfde6bbf64f7f058efa805c6dbb6332d4de6fa Author: Jens Axboe Date: Mon Oct 26 14:32:27 2020 -0600 signal: Add task_sigpending() helper [ Upstream commit 5c251e9dc0e127bac6fc5b8e6696363d2e35f515 ] This is in preparation for maintaining signal_pending() as the decider of whether or not a schedule() loop should be broken, or continue sleeping. This is different than the core signal use cases, which really need to know whether an actual signal is pending or not. task_sigpending() returns non-zero if TIF_SIGPENDING is set. Only core kernel use cases should care about the distinction between the two, make sure those use the task_sigpending() helper. Signed-off-by: Jens Axboe Signed-off-by: Thomas Gleixner Reviewed-by: Thomas Gleixner Reviewed-by: Oleg Nesterov Link: https://lore.kernel.org/r/20201026203230.386348-2-axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman commit ad0b0137953a2c973958dadf6d222e120e278856 Author: Pavel Begunkov Date: Wed Aug 25 12:25:44 2021 +0100 net: add accept helper not installing fd [ Upstream commit d32f89da7fa8ccc8b3fb8f909d61e42b9bc39329 ] Introduce and reuse a helper that acts similarly to __sys_accept4_file() but returns struct file instead of installing file descriptor. Will be used by io_uring. Signed-off-by: Pavel Begunkov Acked-by: Jakub Kicinski Signed-off-by: Jens Axboe Acked-by: David S. Miller Link: https://lore.kernel.org/r/c57b9e8e818d93683a3d24f8ca50ca038d1da8c4.1629888991.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 069ac28d92432dd7cdac0a2c141a1b3b8d4330d5 Author: Jens Axboe Date: Sat Sep 5 11:13:35 2020 -0600 net: provide __sys_shutdown_sock() that takes a socket [ Upstream commit b713c195d59332277a31a59c91f755e53b5b302b ] No functional changes in this patch, needed to provide io_uring support for shutdown(2). Cc: netdev@vger.kernel.org Cc: David S. Miller Acked-by: Jakub Kicinski Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0b8cd5d814cb53d4109d2ba5e73dab38bf49a3b7 Author: Arnaldo Carvalho de Melo Date: Tue Feb 23 09:44:37 2021 -0300 tools headers UAPI: Sync openat2.h with the kernel sources [ Upstream commit 1e61463cfcd0b3e7a19ba36b8a98c64ebaac5c6e ] To pick the changes in: 99668f618062816c ("fs: expose LOOKUP_CACHED through openat2() RESOLVE_CACHED") That don't result in any change in tooling, only silences this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/openat2.h' differs from latest version at 'include/uapi/linux/openat2.h' diff -u tools/include/uapi/linux/openat2.h include/uapi/linux/openat2.h Cc: Al Viro Cc: Jens Axboe Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5683caa7350f389d099b72bfdb289d2073286e32 Author: Jens Axboe Date: Thu Dec 17 09:19:10 2020 -0700 fs: expose LOOKUP_CACHED through openat2() RESOLVE_CACHED [ Upstream commit 99668f618062816ca7ba639b007eb145b9d3d41e ] Now that we support non-blocking path resolution internally, expose it via openat2() in the struct open_how ->resolve flags. This allows applications using openat2() to limit path resolution to the extent that it is already cached. If the lookup cannot be satisfied in a non-blocking manner, openat2(2) will return -1/-EAGAIN. Cc: Al Viro Signed-off-by: Jens Axboe Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 0cf0ce8fb5b10d669072345ea855de112d0e0a43 Author: Al Viro Date: Tue Apr 6 12:33:07 2021 -0400 Make sure nd->path.mnt and nd->path.dentry are always valid pointers [ Upstream commit 7d01ef7585c07afaf487759a48486228cd065726 ] Initialize them in set_nameidata() and make sure that terminate_walk() clears them once the pointers become potentially invalid (i.e. we leave RCU mode or drop them in non-RCU one). Currently we have "path_init() always initializes them and nobody accesses them outside of path_init()/terminate_walk() segments", which is asking for trouble. With that change we would have nd->path.{mnt,dentry} 1) always valid - NULL or pointing to currently allocated objects. 2) non-NULL while we are successfully walking 3) NULL when we are not walking at all 4) contributing to refcounts whenever non-NULL outside of RCU mode. Fixes: 6c6ec2b0a3e0 ("fs: add support for LOOKUP_CACHED") Reported-by: syzbot+c88a7030da47945a3cc3@syzkaller.appspotmail.com Tested-by: Christian Brauner Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 146fe79fff13fea7b5f3a9e913689e07fd4e6432 Author: Al Viro Date: Mon Feb 15 12:03:23 2021 -0500 fix handling of nd->depth on LOOKUP_CACHED failures in try_to_unlazy* [ Upstream commit eacd9aa8cedeb412842c7b339adbaa0477fdd5ad ] After switching to non-RCU mode, we want nd->depth to match the number of entries in nd->stack[] that need eventual path_put(). legitimize_links() takes care of that on failures; unfortunately, failure exits added for LOOKUP_CACHED do not. We could add the logics for that into those failure exits, both in try_to_unlazy() and in try_to_unlazy_next(), but since both checks are immediately followed by legitimize_links() and there's no calls of legitimize_links() other than those two... It's easier to move the check (and required handling of nd->depth on failure) into legitimize_links() itself. [caught by Jens: ... and since we are zeroing ->depth here, we need to do drop_links() first] Fixes: 6c6ec2b0a3e0 "fs: add support for LOOKUP_CACHED" Tested-by: Jens Axboe Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit c1fe7bd3e1aa85865396b464b31f28b094a4353c Author: Jens Axboe Date: Thu Dec 17 09:19:09 2020 -0700 fs: add support for LOOKUP_CACHED [ Upstream commit 6c6ec2b0a3e0381d886d531bd1471dfdb1509237 ] io_uring always punts opens to async context, since there's no control over whether the lookup blocks or not. Add LOOKUP_CACHED to support just doing the fast RCU based lookups, which we know will not block. If we can do a cached path resolution of the filename, then we don't have to always punt lookups for a worker. During path resolution, we always do LOOKUP_RCU first. If that fails and we terminate LOOKUP_RCU, then fail a LOOKUP_CACHED attempt as well. Cc: Al Viro Signed-off-by: Jens Axboe Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 36ec31201a3da85a112dd368be04aee05c713459 Author: Al Viro Date: Mon Jan 4 00:08:41 2021 -0500 saner calling conventions for unlazy_child() [ Upstream commit ae66db45fd309fd1c6d4e846dfc8414dfec7d6ad ] same as for the previous commit - instead of 0/-ECHILD make it return true/false, rename to try_to_unlazy_child(). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e86db87191d8f91dfe787758c6dd646c2bf0c335 Author: Jens Axboe Date: Fri Sep 10 11:18:36 2021 -0600 iov_iter: add helper to save iov_iter state [ Upstream commit 8fb0f47a9d7acf620d0fd97831b69da9bc5e22ed ] In an ideal world, when someone is passed an iov_iter and returns X bytes, then X bytes would have been consumed/advanced from the iov_iter. But we have use cases that always consume the entire iterator, a few examples of that are iomap and bdev O_DIRECT. This means we cannot rely on the state of the iov_iter once we've called ->read_iter() or ->write_iter(). This would be easier if we didn't always have to deal with truncate of the iov_iter, as rewinding would be trivial without that. We recently added a commit to track the truncate state, but that grew the iov_iter by 8 bytes and wasn't the best solution. Implement a helper to save enough of the iov_iter state to sanely restore it after we've called the read/write iterator helpers. This currently only works for IOVEC/BVEC/KVEC as that's all we need, support for other iterator types are left as an exercise for the reader. Link: https://lore.kernel.org/linux-fsdevel/CAHk-=wiacKV4Gh-MYjteU0LwNBSGpWrK-Ov25HdqB1ewinrFPg@mail.gmail.com/ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1500fed00878fd59b2d6a1832b8d3f7c261a5671 Author: Jens Axboe Date: Thu Mar 4 12:21:05 2021 -0700 kernel: provide create_io_thread() helper [ Upstream commit cc440e8738e5c875297ac0e90316745093be7e28 ] Provide a generic helper for setting up an io_uring worker. Returns a task_struct so that the caller can do whatever setup is needed, then call wake_up_new_task() to kick it into gear. Add a kernel_clone_args member, io_thread, which tells copy_process() to mark the task with PF_IO_WORKER. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman