Oleg Nesterov <oleg@xxxxxxxxxx> writes: >> --- 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. Agreed. The coredump to a pipe will still be short. That needs something additional. The problem Olivier Langlois <olivier@xxxxxxxxxxxxxx> reported was core dumps coming up short because TIF_NOTIFY_SIGNAL was being set during a core dump. We can see this with pipe_write returning -ERESTARTSYS on a full pipe if signal_pending which includes TIF_NOTIFY_SIGNAL is true. Looking further if the thread that is core dumping initiated any io_uring work then io_ring_exit_work will use task_work_add to request that thread clean up it's io_uring state. Perhaps we can put a big comment in dump_emit and if we get back -ERESTARTSYS run tracework_notify_signal. I am not seeing any locks held at that point in the coredump, so it should be safe. The coredump is run inside of file_start_write which is the only potential complication. The code flow is complicated but it looks like the entire point of the exercise is to call io_uring_del_task_file on the originating thread. I suppose that keeps the locking of the xarray in io_uring_task simple. Hmm. All of this comes from io_uring_release. How do we get to io_uring_release? The coredump should be catching everything in exit_mm before exit_files? Confused and hopeful someone can explain to me what is going on, and perhaps simplify it. Eric
