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:   Tue, 8 Aug 2017 09:34:15 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Michal Hocko <mhocko@...nel.org>, mgorman@...e.de
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        selinux@...ho.nsa.gov
Subject: Re: suspicious __GFP_NOMEMALLOC in selinux

On Mon, Aug 7, 2017 at 2:58 AM, Michal Hocko <mhocko@...nel.org> wrote:
> On Fri 04-08-17 13:12:04, Paul Moore wrote:
>> On Fri, Aug 4, 2017 at 3:56 AM, Michal Hocko <mhocko@...nel.org> wrote:
> [...]
>> > 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.
>
> OK, there is certainly no hurry for merging this. Thanks!
> --
> Michal Hocko
> SUSE Labs

Merged into selinux/next with this patch description, and your
sign-off (I had to munge the description a bit based on the thread).
Are you okay with this, especially your sign-off?

  commit 476accbe2f6ef69caeebe99f52a286e12ac35aee
  Author: Michal Hocko <mhocko@...nel.org>
  Date:   Thu Aug 3 10:11:52 2017 +0200

   selinux: use GFP_NOWAIT in the AVC kmem_caches

   There is a strange __GFP_NOMEMALLOC usage pattern in SELinux,
   specifically GFP_ATOMIC | __GFP_NOMEMALLOC which doesn't make much
   sense.  GFP_ATOMIC on its own allows to access memory reserves while
   __GFP_NOMEMALLOC dictates we cannot use memory reserves.  Replace this
   with the much more sane GFP_NOWAIT in the AVC code as we can tolerate
   memory allocation failures in that code.

   Signed-off-by: Michal Hocko <mhocko@...nel.org>
   Acked-by: Mel Gorman <mgorman@...e.de>
   Signed-off-by: Paul Moore <paul@...l-moore.com>

-- 
paul moore
www.paul-moore.com