Messages in this thread | | | Date | Mon, 14 Jun 2021 16:10:33 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH] coredump: Limit what can interrupt coredumps |
| |
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.
> --- 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.
| |