On Wed, Nov 6, 2024 at 7:02 AM Bernd Schubert <bschubert@xxxxxxx> wrote: > > > > On 11/5/24 02:08, Pavel Begunkov wrote: > > On 11/4/24 22:15, Bernd Schubert wrote: > >> On 11/4/24 01:28, Pavel Begunkov wrote: > > ... > >>> In general if you need to change something, either stick your > >>> name, so that I know it might be a derivative, or reflect it in > >>> the commit message, e.g. > >>> > >>> Signed-off-by: initial author > >>> [Person 2: changed this and that] > >>> Signed-off-by: person 2 > >> > >> Oh sorry, for sure. I totally forgot to update the commit message. > >> > >> Somehow the initial version didn't trigger. I need to double check to > > > > "Didn't trigger" like in "kernel was still crashing"? > > My initial problem was a crash in iov_iter_get_pages2() on process > kill. And when I tested your initial patch IO_URING_F_TASK_DEAD didn't > get set. Jens then asked to test with the version that I have in my > branch and that worked fine. Although in the mean time I wonder if > I made test mistake (like just fuse.ko reload instead of reboot with > new kernel). Just fixed a couple of issues in my branch (basically > ready for the next version send), will test the initial patch > again as first thing in the morning. > > > > > > FWIW, the original version is how it's handled in several places > > across io_uring, and the difference is a gap for !DEFER_TASKRUN > > when a task_work is queued somewhere in between when a task is > > started going through exit() but haven't got PF_EXITING set yet. > > IOW, should be harder to hit. > > > > Does that mean that the test for PF_EXITING is racy and we cannot > entirely rely on it? Another solution is to mark uring_cmd as io_uring_cmd_mark_cancelable(), which provides a chance to cancel cmd in the current context. Thanks,
