Thread (49 messages) 49 messages, 4 authors, 2020-08-19

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

From: Minchan Kim <minchan@kernel.org>
Date: 2020-08-15 04:59:07
Also in: linux-man

On Fri, Aug 14, 2020 at 07:53:09PM -0700, Linus Torvalds wrote:
On Fri, Aug 14, 2020 at 5:31 PM Andrew Morton [off-list ref] wrote:
quoted
From: Minchan Kim <minchan@kernel.org>
Subject: mm/madvise: check fatal signal pending of target process

Bail out to prevent unnecessary CPU overhead if target process has pending
fatal signal during (MADV_COLD|MADV_PAGEOUT) operation.
This seems bogus.

Returning -EINTR when *SOMEBODY ELSE* has a signal is crazy talk.
It doesn't propagate -EINTR to the user but just aiming for canceling
the entire operation.
It also seems to be the reason for the previous patches inexplicably
passing in the task pointer.

Finally, it has absolutely no explanations for why this would matter,
and why it's magically and suddenly an issue for process_madvise(),
when in the history of the *real* madvise() this hasn't been an issue
for "current".
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.
I'm dropping the madvise() series.

If the issue is that you can generate a long series or areas with that
iovec, maybe the code should re-consider. Or maybe the signal pending
case should be done there, not passing down an odd task pointer to the
low-level madvise code.
Do you mean you want to drop target signal check madvise as well as
process_madvise?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help