Re: [PATCH] coredump: Limit what can interrupt coredumps
From: Oleg Nesterov <oleg@redhat.com>
Date: 2021-06-14 14:10:42
Also in:
linux-fsdevel, lkml
Possibly related (same subject, not in this thread)
- 2021-08-21 · Re: [PATCH] coredump: Limit what can interrupt coredumps · Olivier Langlois <hidden>
- 2021-08-21 · Re: [PATCH] coredump: Limit what can interrupt coredumps · Jens Axboe <axboe@kernel.dk>
- 2021-08-21 · Re: [PATCH] coredump: Limit what can interrupt coredumps · Olivier Langlois <hidden>
- 2021-08-21 · Re: [PATCH] coredump: Limit what can interrupt coredumps · Olivier Langlois <hidden>
- 2021-08-21 · Re: [PATCH] coredump: Limit what can interrupt coredumps · Olivier Langlois <hidden>
Eric, et al, sorry for delay, I didn't read emails several days. On 06/10, Eric W. Biederman wrote:
v2: Don't remove the now unnecessary code in prepare_signal.
No, that code is still needed. Otherwise any fatal signal will be turned into SIGKILL.
quoted hunk ↗ jump to hunk
--- a/fs/coredump.c +++ b/fs/coredump.c@@ -519,7 +519,7 @@ static bool dump_interrupted(void) * but then we need to teach dump_write() to restart and clear * TIF_SIGPENDING. */ - return signal_pending(current); + return fatal_signal_pending(current) || freezing(current); }
Well yes, this is what the comment says. But note that there is another reason why dump_interrupted() returns true if signal_pending(), it assumes thagt __dump_emit()->__kernel_write() may fail anyway if signal_pending() is true. Say, pipe_write(), or iirc nfs, perhaps something else... That is why zap_threads() clears TIF_SIGPENDING. Perhaps it should clear TIF_NOTIFY_SIGNAL as well and we should change io-uring to not abuse the dumping threads? Or perhaps we should change __dump_emit() to clear signal_pending() and restart __kernel_write() if it fails or returns a short write. Otherwise the change above doesn't look like a full fix to me. Oleg.