Re: [patch 18/39] mm/madvise: check fatal signal pending of target process

[Minchan Kim <minchan@kernel.org>]

On Sat, Aug 15, 2020 at 07:57:15AM -0700, Linus Torvalds wrote:
> On Fri, Aug 14, 2020 at 9:59 PM Minchan Kim <minchan@kernel.org> wrote:
> >
> > Currently, madvise(MADV_COLD|PAGEOUT) already have done it. I just wanted
> > to sync with it with process_madvise. Ting was process_madvise couldn't
> > get target task while madvise could get it easily.
> 
> The thing is, for "current" it makes sense.
> 
> It makes sense because "current" is also the one doing the action, so
> when current is dying, stopping the action is sane too.

True.

> 
> But when you target somebody else, the signal handling simply doesn't
> make any sense at all.
> 
> It doesn't make sense because the error code doesn't make sense (EINTR
> really is about the _actor_ getting interrupted, not the target), but
> it also doesn't make sense simply because there is no 1:1 relationship
> between the target mm and the target thread.
> 
> The pid that was the target may be dying, but that does *not* mean
> that the mm itself is dying. So stopping the operation arbitrarily
> somewhere in the middle is a fundamentally insane operation.  You've
> done something partial to a mm that may well still be active.
> 
> So I think it's simply conceptually wrong to look at some "target
> thread signal state" in ways that it isn't to look at "current signal
> state".

Agreed.

> 
> Now, it might be worth it to have some kind of "this mm is dying,
> don't bother" thing. We _kind_ of have things like that already in the
> form of the MMF_OOM_VICTIM flag (and TIF_MEMDIE is the per-thread
> image of it).
> 
> It might be reasonable to have a MMF_DYING flag, but I'm not even sure
> how to implement it, exactly because of that "this thread group may be
> dying, but the MM might still be attached to other tasks" issue.
> 
> For example, if you do "vfork()" and the child is killed, the mm is
> still active and attached to the vfork() parent.

Maybe, we could use mm_struct's mm_users to check caller is exclusive
owner so that rest of all are existing.

> 
> Similarly, on a trivial level, a particular thread might be killed
> without the rest of the threads being necessarily killed.
> 
> Again, for regular "madvise()" it makes sense to look at whether the
> _current_ thread is being killed - because that fundamentally
> interrupts the operator. But for somebody else, operating on the mm of
> a thread, I really think it's wrong to look at the target thread state
> and leave the MM operation in some half-way state.

I agreed. I will drop this single patch with revising previous patch
not to make passing task_struct since the idea.
We could revist if someting real trouble happens.

Please tell me if you found something weird in this patchset series
so that in next cycle we could go smooth.

Thanks for the review, Linus.