From: Matthew Wilcox <willy@infradead.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
kirill.shutemov@linux.intel.com, mhocko@suse.com,
riel@redhat.com
Subject: Re: [PATCH] mm: Check for SIGKILL inside dup_mmap() loop.
Date: Tue, 3 Apr 2018 05:14:14 -0700 [thread overview]
Message-ID: <20180403121414.GD5832@bombadil.infradead.org> (raw)
In-Reply-To: <201803301934.DHF12420.SOFFJQMLVtHOOF@I-love.SAKURA.ne.jp>
On Fri, Mar 30, 2018 at 07:34:59PM +0900, Tetsuo Handa wrote:
> Maybe we can make "give up by default upon SIGKILL" and let callers
> explicitly say "do not give up upon SIGKILL".
I really strongly disapprove of this patch. This GFP flag will be abused
like every other GFP flag.
> +++ b/mm/page_alloc.c
> @@ -4183,6 +4183,13 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> if (current->flags & PF_MEMALLOC)
> goto nopage;
>
> + /* Can give up if caller is willing to give up upon fatal signals */
> + if (fatal_signal_pending(current) &&
> + !(gfp_mask & (__GFP_UNKILLABLE | __GFP_NOFAIL))) {
> + gfp_mask |= __GFP_NOWARN;
> + goto nopage;
> + }
> +
> /* Try direct reclaim and then allocating */
This part is superficially tempting, although without the UNKILLABLE. ie:
+ if (fatal_signal_pending(current) && !(gfp_mask & __GFP_NOFAIL)) {
+ gfp_mask |= __GFP_NOWARN;
+ goto nopage;
+ }
It makes some sense to me to prevent tasks with a fatal signal pending
from being able to trigger reclaim. But I'm worried about what memory
allocation failures it might trigger on paths that aren't accustomed to
seeing failures.
next prev parent reply other threads:[~2018-04-03 12:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 11:27 Tetsuo Handa
2018-03-29 21:30 ` Andrew Morton
2018-03-30 10:34 ` Tetsuo Handa
2018-04-03 12:14 ` Matthew Wilcox [this message]
2018-04-03 12:19 ` Michal Hocko
2018-04-03 12:25 ` Matthew Wilcox
2018-04-03 14:54 ` Tetsuo Handa
2018-04-03 12:29 ` Tetsuo Handa
2018-04-03 13:06 ` Michal Hocko
2018-04-03 11:16 ` Michal Hocko
2018-04-03 11:32 ` Tetsuo Handa
2018-04-03 11:38 ` Michal Hocko
2018-04-03 11:58 ` Matthew Wilcox
2018-04-03 12:08 ` Michal Hocko
2018-04-07 10:38 ` Tetsuo Handa
2018-04-18 21:44 ` Andrew Morton
2018-04-19 1:54 ` Tetsuo Handa
2018-04-19 2:32 ` Andrew Morton
2018-06-07 22:05 ` Andrew Morton
2018-06-08 17:05 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180403121414.GD5832@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=riel@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox