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

[Linus Torvalds <torvalds@linux-foundation.org>]

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.

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

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.

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.

                         Linus