Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Jan 04, 2023
-
-
Jens Axboe authored
[ Upstream commit 03941ccf ] All archs now support TIF_NOTIFY_SIGNAL. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Al Viro authored
[ Upstream commit e2c7554c ] it needs to be added to _TIF_WORK_MASK, or we might not reach do_work_pending() in the first place... Fixes: 5a9a8897 "alpha: add support for TIF_NOTIFY_SIGNAL" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit bb12433b ] 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 <TIF_SIGPENDING> worked. New code needs to check multiple bits so AND <bit-mask> instruction. So needs to use bit mask variant _TIF_SIGPENDING Cc: Jens Axboe <axboe@kernel.dk> Fixes: 53855e12 ("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 <vgupta@synopsys.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit f5f4fc46 ] 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: b269c229 ("ia64: add support for TIF_NOTIFY_SIGNAL") Reported-by:
Sergei Trofimovich <slyich@gmail.com> Reported-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by:
-
Jens Axboe authored
[ Upstream commit f50a7052 ] Wire up TIF_NOTIFY_SIGNAL handling for sparc. Cc: sparclinux@vger.kernel.org Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 24a31b81 ] Wire up TIF_NOTIFY_SIGNAL handling for riscv. Cc: linux-riscv@lists.infradead.org Signed-off-by:
-
Jens Axboe authored
[ Upstream commit b13e8bf6 ] Wire up TIF_NOTIFY_SIGNAL handling for nds32. Cc: Nick Hu <nickhu@andestech.com> Cc: Greentime Hu <green.hu@gmail.com> Cc: Vincent Chen <deanbo422@gmail.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit b269c229 ] Wire up TIF_NOTIFY_SIGNAL handling for ia64. Cc: linux-ia64@vger.kernel.org [axboe: added fixes from Mike Rapoport <rppt@kernel.org>] Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 2f9799ad ] Wire up TIF_NOTIFY_SIGNAL handling for h8300. Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 6d665a4d ] Wire up TIF_NOTIFY_SIGNAL handling for c6x. Cc: linux-c6x-dev@linux-c6x.org Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 5a9a8897 ] Wire up TIF_NOTIFY_SIGNAL handling for alpha. Cc: linux-alpha@vger.kernel.org Signed-off-by:
-
Jens Axboe authored
[ Upstream commit bec58f40 ] Wire up TIF_NOTIFY_SIGNAL handling for xtensa. Thanks to Max Filippov <jcmvbkbc@gmail.com> for making the asm correct. Cc: linux-xtensa@linux-xtensa.org Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 32d59773 ] Wire up TIF_NOTIFY_SIGNAL handling for arm. Cc: linux-arm-kernel@lists.infradead.org Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit f4ea089e ] Wire up TIF_NOTIFY_SIGNAL handling for microblaze. Acked-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit aeec8193 ] Wire up TIF_NOTIFY_SIGNAL handling for hexagon. Cc: linux-hexagon@vger.kernel.org Acked-by:
Brian Cain <bcain@codeaurora.org> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit f3924d76 ] Wire up TIF_NOTIFY_SIGNAL handling for csky. Cc: linux-csky@vger.kernel.org Acked-by:
Guo Ren <guoren@kernel.org> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit e181c0aa ] Wire up TIF_NOTIFY_SIGNAL handling for openrisc. Cc: openrisc@lists.librecores.org Acked-by:
Stafford Horne <shorne@gmail.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 6d3a2733 ] Wire up TIF_NOTIFY_SIGNAL handling for sh. Cc: linux-sh@vger.kernel.org Signed-off-by:
-
Jens Axboe authored
[ Upstream commit a5b3cd32 ] Wire up TIF_NOTIFY_SIGNAL handling for um. Cc: linux-um@lists.infradead.org Acked-By:
Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 75309018 ] Wire up TIF_NOTIFY_SIGNAL handling for s390. Cc: linux-s390@vger.kernel.org Acked-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit f45c184b ] Wire up TIF_NOTIFY_SIGNAL handling for mips. Cc: linux-mips@vger.kernel.org Acked-By:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 900f0713 ] Wire up TIF_NOTIFY_SIGNAL handling for powerpc. Cc: linuxppc-dev@lists.ozlabs.org Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 18cb3281 ] Wire up TIF_NOTIFY_SIGNAL handling for parisc. Cc: linux-parisc@vger.kernel.org Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 42020064 ] Wire up TIF_NOTIFY_SIGNAL handling for nios32. Cc: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by:
Ley Foon Tan <ley.foon.tan@intel.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit e660653c ] Wire up TIF_NOTIFY_SIGNAL handling for m68k. Cc: linux-m68k@lists.linux-m68k.org Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 192caabd ] Wire up TIF_NOTIFY_SIGNAL handling for arm64. Cc: linux-arm-kernel@lists.infradead.org Acked-by:
Will Deacon <will@kernel.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 53855e12 ] Wire up TIF_NOTIFY_SIGNAL handling for arc. Cc: linux-snps-arc@lists.infradead.org Acked-by:
-
Jens Axboe authored
[ Upstream commit c8d5ed67 ] 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:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201026203230.386348-4-axboe@kernel.dk Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 114518eb ] 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 0ba9c9ed. Reported-by:
Roman Gershman <romger@amazon.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20201026203230.386348-5-axboe@kernel.dk Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 12db8b69 ] 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 authored
[ Upstream commit 53dec2ea ] 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:
-
Eric W. Biederman authored
[ Upstream commit 9fe83c43 ] 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] 80cd7956 ("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 <ebiederm@xmission.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit e886663c ] 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 authored
[ Upstream commit 5c251e9d ] 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:
-
Pavel Begunkov authored
[ Upstream commit d32f89da ] 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 <asml.silence@gmail.com> Acked-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/c57b9e8e818d93683a3d24f8ca50ca038d1da8c4.1629888991.git.asml.silence@gmail.com Signed-off-by:
-
Jens Axboe authored
[ Upstream commit b713c195 ] No functional changes in this patch, needed to provide io_uring support for shutdown(2). Cc: netdev@vger.kernel.org Cc: David S. Miller <davem@davemloft.net> Acked-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 1e61463c ] To pick the changes in: 99668f61 ("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 <viro@zeniv.linux.org.uk> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 99668f61 ] 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 <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
[ Upstream commit 7d01ef75 ] 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: 6c6ec2b0 ("fs: add support for LOOKUP_CACHED") Reported-by:
<syzbot+c88a7030da47945a3cc3@syzkaller.appspotmail.com> Tested-by:
Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit eacd9aa8 ] 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: 6c6ec2b0 "fs: add support for LOOKUP_CACHED" Tested-by:
-
