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]
Message-ID: <CAHC9VhR_SJUg2wkKhoeXHJeLrNFh=KYwSgz-5X57xx0Maa95Mg@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ