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
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
-
Abhimanyu Raj abhimanyu.raj
- Mar 01, 2023
-
-
Jens Axboe authored
commit 4c3c0943 upstream. Like commit 7ba89d2a for recv/recvmsg, support MSG_WAITALL for the send side. If this flag is set and we do a short send, retry for a stream of seqpacket socket. Change-Id: If67a4462576af1b683d53d2dc0d46e44c9dd8863 Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org> Bug: 268174392 (cherry picked from commit f901b4bf) Signed-off-by:
Greg Kroah-Hartman <gregkh@google.com>
-
Jens Axboe authored
commit 8a3e8ee5 upstream. If we need to continue doing this IO, then we don't want a potentially selected buffer recycled. Add a flag for that. Set this for recv/recvmsg if they do partial IO. Change-Id: If9381bd6a5695c8c85c7a51c3adccc0dc09f8999 Signed-off-by:
-
Jens Axboe authored
commit 7ba89d2a upstream. We currently don't attempt to get the full asked for length even if MSG_WAITALL is set, if we get a partial receive. If we do see a partial receive, then just note how many bytes we did and return -EAGAIN to get it retried. The iov is advanced appropriately for the vector based case, and we manually bump the buffer and remainder for the non-vector case. Cc: stable@vger.kernel.org Reported-by:
Constantine Gavrilov <constantine.gavrilov@gmail.com> Change-Id: I618bde7c86b29f6053dd8cd19682f2916e57dd54 Signed-off-by:
-
Pavel Begunkov authored
commit 7297ce3d upstream. Hide all error handling under common if block, removes two extra ifs on the success path and keeps the handling more condensed. Change-Id: If6864c8ddd06bc853cef6b543fc06cf99d9ad147 Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/5761545158a12968f3caf30f747eea65ed75dfc1.1637524285.git.asml.silence@gmail.com Signed-off-by:
-
Jens Axboe authored
commit 46a525e1 upstream. This isn't a reliable mechanism to tell if we have task_work pending, we really should be looking at whether we have any items queued. This is problematic if forward progress is gated on running said task_work. One such example is reading from a pipe, where the write side has been closed right before the read is started. The fput() of the file queues TWA_RESUME task_work, and we need that task_work to be run before ->release() is called for the pipe. If ->release() isn't called, then the read will sit forever waiting on data that will never arise. Fix this by io_run_task_work() so it checks if we have task_work pending rather than rely on TIF_NOTIFY_SIGNAL for that. The latter obviously doesn't work for task_work that is queued without TWA_SIGNAL. Reported-by:
Christiano Haesbaert <haesbaert@haesbaert.org> Cc: stable@vger.kernel.org Link: https://github.com/axboe/liburing/issues/665 Change-Id: I042b07491afac06692639d91bdf7dd21a2405651 Signed-off-by:
-
Jens Axboe authored
commit e6db6f93 upstream. We have two types of task_work based creation, one is using an existing worker to setup a new one (eg when going to sleep and we have no free workers), and the other is allocating a new worker. Only the latter should be freed when we cancel task_work creation for a new worker. Fixes: af82425c ("io_uring/io-wq: free worker if task_work creation is canceled") Reported-by:
<syzbot+d56ec896af3637bdb7e4@syzkaller.appspotmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 268174392 (cherry picked from commit a88a0d16) Signed-off-by:
-
Jens Axboe authored
commit af82425c upstream. If we cancel the task_work, the worker will never come into existance. As this is the last reference to it, ensure that we get it freed appropriately. Cc: stable@vger.kernel.org Reported-by:
진호 <wnwlsgh98@gmail.com> Signed-off-by:
-
Harshit Mogalapalli authored
Smatch warning: io_fixup_rw_res() warn: unsigned 'res' is never less than zero. Change type of 'res' from unsigned to long. Fixes: d6b7efc722a2 ("io_uring/rw: fix error'ed retry return values") Signed-off-by:Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by:
-
- Feb 15, 2023
-
-
Bian Jin chen authored
2 function symbol(s) added 'int drm_connector_attach_content_protection_property(struct drm_connector *, bool)' 'void drm_hdcp_update_content_protection(struct drm_connector *, u64)' Bug: 239396464 Signed-off-by:
Kever Yang <kever.yang@rock-chips.com> Signed-off-by:
Bian Jin chen <kenjc.bian@rock-chips.com> Change-Id: I04b97183606cb6bcf565c5021559fa1038c161b1
-
- Feb 13, 2023
-
-
Rob Herring authored
The current ATU setup only supports a single memory resource which isn't sufficient if there are also prefetchable memory regions. In order to support multiple memory regions, we need to move away from fixed ATU slots and rework the assignment. As there's always an ATU entry for config space, let's assign index 0 to config space. Then we assign memory resources to index 1 and up. Finally, if we have an I/O region and slots remaining, we assign the I/O region last. If there aren't remaining slots, we keep the same config and I/O space sharing. Bug: 268559201 Link: https://lore.kernel.org/r/20201026181652.418729-1-robh@kernel.org Tested-by:
Vidya Sagar <vidyas@nvidia.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Jingoo Han <jingoohan1@gmail.com> Cc: Vidya Sagar <vidyas@nvidia.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Jon Lin <jon.lin@rock-chips.com> Change-Id: Ib945de723c29a80f055227474a01806283bd1873 (cherry picked from commit 9f9e59a4) [Revert the struct change to keep KMI and setting DWC_IATU_IOCFG_SHARED in a vendor hook so that not to affect vendor modules not use it] Signed-off-by:
-
- Feb 10, 2023
-
-
Maulik Shah authored
This change fixes suspicious RCU usage warnings from vendor hook. ============================= WARNING: suspicious RCU usage 5.15.41-debug-gc1163f69ba3b-dirty #1 Not tainted ----------------------------- include/trace/events/lock.h:37 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 RCU used illegally from extended quiescent state! no locks held by swapper/0/0. stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.41-debug-gc1163f69ba3b-dirty #1 Call trace: dump_backtrace+0x0/0x1d8 dump_stack+0x1c/0x4c .. .. _printk+0x58/0x84 lockdep_rcu_suspicious+0x44/0x15c trace_android_vh_printk_caller_id+0xc4/0x13c vprintk_store+0x54/0x59c vprintk_emit+0x8c/0x130 vprintk_default+0x48/0x74 vprintk+0xf8/0x13c _printk+0x58/0x84 lockdep_rcu_suspicious+0x44/0x15c trace_android_vh_cpuidle_psci_enter+0xc4/0x144 __psci_enter_domain_idle_state+0x64/0x118 psci_enter_domain_idle_state+0x1c/0x2c cpuidle_enter_state+0x14c/0x2fc cpuidle_enter+0x3c/0x58 Bug: 267847290 Fixes: 3567f516 ("ANDROID: cpuidle-psci: Add vendor hook for cpuidle psci enter and exit") Change-Id: I910a6a0595c3a79b75e581297eb56d512ce5885c Signed-off-by:Maulik Shah <quic_mkshah@quicinc.com>
-
Ray Chi authored
1 function symbol(s) added 'void usb_udc_vbus_handler(struct usb_gadget *, bool)' Bug: 267846601 Change-Id: Ie1e8a39eca7c610b410a8768d3f3ba32eed9a46d Signed-off-by:Ray Chi <raychi@google.com>
-
- Feb 09, 2023
-
-
Greg Kroah-Hartman authored
In commit 76050cdc ("UPSTREAM: io_uring: import 5.15-stable io_uring"), a new field was added to struct task_struct. Move it to the proper location and macro in order to preserve the kernel ABI. Because of this preservation, the .xml file also is updated: type 'struct task_struct' changed member 'union { void* pf_io_worker; struct { u64 android_kabi_reserved1; }; union { }; }' was added member 'u64 android_kabi_reserved1' was removed Bug: 161946584 Bug: 268174392 Fixes: 76050cdc ("UPSTREAM: io_uring: import 5.15-stable io_uring") Signed-off-by:
-
Greg Kroah-Hartman authored
In the 5.10.162 release, the io_uring code was synced with the version that is in the 5.15.y kernel tree in order to resolve a huge number of potential, and known, problems with the codebase. This makes for a more secure and easier-to-update-and-maintain 5.10.y kernel tree, so this is a great thing, however this caused some issues when it comes to the Android KABI preservation and checking tools. A number of the io_uring structures get used in other core kernel structures, only as "opaque" pointers, so there is not any real ABI breakage. But, due to the visibility of the structures going away, the CRC values of many scheduler variables and functions were changed. In order to preserve the CRC values, to prevent all device kernels to be forced to rebuild for no reason whatsoever from a functional point of view, we need to keep around the "old" io_uring structures for the CRC calculation only. This is done by the following definitions of struct io_identity and struct io_uring_task which will only be visible when the CRC calculation build happens, not in any functional kernel build. Yes, this all is a horrible hack, and these really are not the true structures that any code uses, but so life is in the world of stable apis. Bug: 161946584 Bug: 268174392 Fixes: 76050cdc ("UPSTREAM: io_uring: import 5.15-stable io_uring") Signed-off-by:
-
Greg Kroah-Hartman authored
In commit a2b8beeb ("UPSTREAM: net: remove cmsg restriction from io_uring based send/recvmsg calls") the flags variable was removed from struct proto_ops as it is no longer needed. But the ABI signatures break, so put it back to preserve this, there's no functional change here. Bug: 161946584 Bug: 268174392 Fixes: a2b8beeb ("UPSTREAM: net: remove cmsg restriction from io_uring based send/recvmsg calls") Change-Id: Ic6a868f038701a61c993e18b44cdd8ec8b0a4d58 Signed-off-by:
-
- Feb 08, 2023
-
-
Jens Axboe authored
[ Upstream commit 44648532 ] 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. Bug: 268174392 Cc: stable@vger.kernel.org # 6.0 Change-Id: I6e45fa1484657bd5caad007783785c2ee97a9929 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 03e02acd ] 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] Change-Id: I0c38a56887777f85cb10673b7ca3b5ca4d70c61b Signed-off-by:
-
Jens Axboe authored
[ Upstream commit caf1aeaf ] 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 Change-Id: Ifafcb236b2cfe3ca3e7254a0155625fce00fd038 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 9e8d9e82 ] This reverts commit 8d4c3e76. No longer needed, as the io-wq worker threads have the right identity. Change-Id: I6c12f6f957e1c789f4fd5b21379d167f17feb3ea Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 2587890b ] This reverts commit 0d4370cf. No longer needed, as the io-wq worker threads have the right identity. Change-Id: I7a28e02a0a1911555853cf4046e3a09c7e36d4a2 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit e5493796 ] 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. Change-Id: Ie87e4ff3c621cf53a8e9589a7689e62d759de983 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 35d0b389 ] 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: 98b89b64 ("signal: kill JOBCTL_TASK_WORK") Reported-by:
Song Liu <songliubraving@fb.com> Tested-by:
John Stultz <john.stultz@linaro.org> Tested-by:
Douglas Anderson <dianders@chromium.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang version 11.0.1 Change-Id: Id5ce292120cafff9ede9bb7421cde3aaf4e56924 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 98b89b64 ] It's no longer used, get rid of it. Change-Id: Id14379554f3e1085c63ac4d044618f609ebc2f9f Signed-off-by:
-
Jens Axboe authored
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 Change-Id: I7ce5226d6b39763ffc246fd6357cece9aafd4b59 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit c7aab1a7 ] 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 <oleg@redhat.com> Change-Id: Ia33480d209b26d433a3ca196972d6931aa4f8dde Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 10442994 ] 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. Change-Id: Iedc3fae8cb496d003852c87fdefacc1ad7601cc5 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit b16b3855 ] 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" <ebiederm@xmission.com> Reported-by:
-
Stefan Metzmacher authored
[ Upstream commit 50b7b6f2 ] 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: 4727dc20 ("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 Change-Id: I83793e9a4fbc5f9024c9aeace0640043c81a93b0 Signed-off-by:
Stefan Metzmacher <metze@samba.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: Jens Axboe <axboe@kernel.dk> cc: Andy Lutomirski <luto@kernel.org> 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 <tglx@linutronix.de> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 0100e6bb ] 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 <bgoncalv@redhat.com> Fixes: 4727dc20 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Change-Id: I3d0289912eb9e4545fc0b680df6890b6b837ebdd Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 4727dc20 ] 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(). Change-Id: Iec4a3c42a39f016b323476d7238f3d36aaf0e6cf Signed-off-by:
-
Seth Forshee authored
[ Upstream commit 3e684903 ] 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:
Seth Forshee <sforshee@digitalocean.com> Message-Id: <20220504180840.2907296-1-sforshee@digitalocean.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 66ae0d1e ] 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(). Change-Id: Iec007746b42f5d62581a8b5f6cca4006e707b8e3 Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 06af8679 ] Olivier Langlois has been struggling with coredumps being incompletely written in processes using io_uring. Olivier Langlois <olivier@trillion01.com> 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: 12db8b69 ("entry: Add support for TIF_NOTIFY_SIGNAL") Reported-by:
Olivier Langlois <olivier@trillion01.com> Change-Id: I84870bf0a620a97af50d9b495dd225f9ee2b66b8 Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit e296dc49 ] It's available everywhere now, no need to check or add dummy defines. Change-Id: I2e0950c13a90b463b848bb6bc095db02ae08a8cd Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 03941ccf ] All archs now support TIF_NOTIFY_SIGNAL. Change-Id: I3fc938645ac7be18300432713909ccfaa7cd2711 Signed-off-by:
-
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" Change-Id: I9f19ad6bc9833ce0cc103163af7904862425badb 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 Change-Id: I00aa9a6c3118f72e90575fb7ca4ebc08300b542e 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 Change-Id: I6dc91c146efed1287ead67fa44db9185576cbce8 Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 24a31b81 ] Wire up TIF_NOTIFY_SIGNAL handling for riscv. Cc: linux-riscv@lists.infradead.org Change-Id: Ia1d9bc9779bf2935dc5a7c83e86261123d4d6b0f Signed-off-by:
-
