From: Paul Moore <paul@paul-moore.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
mgorman@suse.de, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, selinux@tycho.nsa.gov
Subject: Re: suspicious __GFP_NOMEMALLOC in selinux
Date: Fri, 4 Aug 2017 13:12:04 -0400 [thread overview]
Message-ID: <CAHC9VhR_SJUg2wkKhoeXHJeLrNFh=KYwSgz-5X57xx0Maa95Mg@mail.gmail.com> (raw)
In-Reply-To: <20170804075636.GD26029@dhcp22.suse.cz>
On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 03-08-17 14:17:26, Paul Moore wrote:
>> On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko <mhocko@kernel.org> wrote:
>> > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote:
> [...]
>> >> When allocating thread is selected as an OOM victim, it gets TIF_MEMDIE.
>> >> Since that function might be called from !in_interrupt() context, it is
>> >> possible that gfp_pfmemalloc_allowed() returns true due to TIF_MEMDIE and
>> >> the OOM victim will dip into memory reserves even when allocation failure
>> >> is not a problem.
>> >
>> > Yes this is possible but I do not see any major problem with that.
>> > I wouldn't add __GFP_NOMEMALLOC unless there is a real runaway of some
>> > sort that could be abused.
>>
>> Adding __GFP_NOMEMALLOC would not hurt anything would it?
>
> I is not harmfull but I fail to see how it would be useful either and as
> such it just adds a pointless gfp flag and confusion to whoever tries to
> modify the code in future. Really the main purpose of __GFP_NOMEMALLOC
> is to override the process scope PF_MEMALLOC. As such it is quite a hack
> and the fewer users we have the better.
Okay, that is a viable explanation for me.
> Btw. Should I resend the patch or somebody will take it from this email
> thread?
No, unless your mailer mangled the patch I should be able to pull it
from this thread. However, I'm probably going to let this sit until
early next week on the odd chance that anyone else wants to comment on
the flag choice. I'll send another reply once I merge the patch.
--
paul moore
www.paul-moore.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-08-04 17:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 10:50 Michal Hocko
2017-08-02 21:45 ` Paul Moore
2017-08-03 8:11 ` Michal Hocko
2017-08-03 8:56 ` Mel Gorman
2017-08-03 10:02 ` Tetsuo Handa
2017-08-03 10:33 ` Michal Hocko
2017-08-03 10:44 ` Tetsuo Handa
2017-08-03 11:05 ` Michal Hocko
2017-08-03 18:17 ` Paul Moore
2017-08-04 7:56 ` Michal Hocko
2017-08-04 17:12 ` Paul Moore [this message]
2017-08-07 6:58 ` Michal Hocko
2017-08-08 13:34 ` Paul Moore
2017-08-10 7:02 ` Michal Hocko
2017-08-10 13:49 ` Paul Moore
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='CAHC9VhR_SJUg2wkKhoeXHJeLrNFh=KYwSgz-5X57xx0Maa95Mg@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=selinux@tycho.nsa.gov \
/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