On 2/14/20 10:25 AM, Jann Horn wrote: > +Jens and io-uring list > > On Fri, Feb 14, 2020 at 6:06 PM Minchan Kim <minchan@xxxxxxxxxx> wrote: >> In upcoming patches, do_madvise will be called from external process >> context so we shouldn't asssume "current" is always hinted process's >> task_struct. > [...] >> [1] http://lore.kernel.org/r/CAG48ez27=pwm5m_N_988xT1huO7g7h6arTQL44zev6TD-h-7Tg@xxxxxxxxxxxxxx > [...] >> diff --git a/fs/io_uring.c b/fs/io_uring.c > [...] >> @@ -2736,7 +2736,7 @@ static int io_madvise(struct io_kiocb *req, struct io_kiocb **nxt, >> if (force_nonblock) >> return -EAGAIN; >> >> - ret = do_madvise(ma->addr, ma->len, ma->advice); >> + ret = do_madvise(current, current->mm, ma->addr, ma->len, ma->advice); >> if (ret < 0) >> req_set_fail_links(req); >> io_cqring_add_event(req, ret); > > Jens, can you have a look at this change and the following patch > <https://lore.kernel.org/linux-mm/20200214170520.160271-4-minchan@xxxxxxxxxx/> > ("[PATCH v5 3/7] mm: check fatal signal pending of target process")? > Basically Minchan's patch tries to plumb through the identity of the > target task so that if that task gets killed in the middle of the > operation, the (potentially long-running and costly) madvise operation > can be cancelled. Just passing in "current" instead (which in this > case is the uring worker thread AFAIK) doesn't really break anything, > other than making the optimization not work, but I wonder whether this > couldn't be done more cleanly - maybe by passing in NULL to mean "we > don't know who the target task is", since I think we don't know that > here? Thanks for bringing this to my attention, patches that touch io_uring (or anything else) really should be CC'ed to the maintainer(s) of those areas... Yeah, the change above won't do the right thing for io_uring, in fact it'll always be the wrong task. So I'd second Jann's question, and ask if we really need the actual task, or if NULL could be used? For cancelation purposes, I'm guessing you want the task that's actually doing the operation, even if it's on behalf of someone else. That makes the interface a bit weird, as you'd assume the task/mm passed in would be related to the madvise itself, not just for cancelation. Would be nice with some clarification, so we can figure out an approach that would actually work. -- Jens Axboe
