linux-kernel - Re: suspicious __GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Aug 2017 13:12:04 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, mgorman@...e.de,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        selinux@...ho.nsa.gov
Subject: Re: suspicious __GFP_NOMEMALLOC in selinux

On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko <mhocko@...nel.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@...nel.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