diff options
| author | Christian Brauner <brauner@kernel.org> | 2026-09-21 15:44:54 +0200 |
|---|---|---|
| committer | Christian Brauner <brauner@kernel.org> | 2026-09-22 15:32:36 +0200 |
| commit | c0e659511d4f49087da095a95799edb5b775a705 (patch) | |
| tree | d4a7ab0282a46c9c858fea62c299899735961f93 /tools/lib/python/kdoc/python_version.py | |
| parent | 0e5663856b69219ef2f02e04bac9f5c5be19718a (diff) | |
| download | linux-next-c0e659511d4f49087da095a95799edb5b775a705.tar.gz linux-next-c0e659511d4f49087da095a95799edb5b775a705.zip | |
signal: don't retarget shared signals in a dying thread group
If the calling thread has blocked a signal then
retarget_shared_pending() slingshots a shared pending signal to a
sibling thread. Today it only skips PF_EXITING threads but not a
coredumping thread.
But if SIGNAL_GROUP_EXIT is set no thread in the thread-group can
dequeue such signals anymore as get_signal() sends SIGKILL to every
thread and prepare_signal() drops any other signal.
exit_signals() also returns early on SIGNAL_GROUP_EXIT. But neither
sigprocmask() nor the mask restore in sigtimedwait() do.
Say a thread sleeps in sigtimedwait() and a sibling thread crashes. The
sleeping thread gets woken by the zap call. It restores its mask on the
way out and retargets a signal that was queued for the coredumping
process. That means TIF_SIGPENDING is set on the coredumping task which
zap_threads() had cleared. So a blocking write sees TIF_SIGPENDING and
truncates the dump.
Stop retargeting signals when SIGNAL_GROUP_EXIT is set and avoid
needlessly truncating coredumps.
Fixes: e6fa16ab9c1e ("signal: sigprocmask() should do retarget_shared_pending()")
Cc: stable@vger.kernel.org
Acked-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-5-8e4adb1619e6@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
