Re: [PATCH v5 1/7] mm: pass task and mm to do_madvise

[Minchan Kim]

On Fri, Feb 14, 2020 at 11:22:08AM -0700, Jens Axboe wrote:
> 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...

Hi Jens, it was my mistake. Sorry for that.

> 
> 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.

MADV_(COLD|PAGEOUT) checks both caller and callee and the part aims for
callee(ie, target task). Thus, we could pass NULL for io_madvise if
it couldn't know who is target and let's have NULL check before the
fatal_signal_pending. I will put following checks in [3/7].

	if (private->target_Task &&
			fatal_signal_pending(private->target_task))
		return -EINTR;