linux-kernel - Re: [PATCH v2 2/4] mm/vmalloc: add support for __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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 24 Nov 2021 14:16:56 +1100
From:   "NeilBrown" <neilb@...e.de>
To:     "Andrew Morton" <akpm@...ux-foundation.org>
Cc:     "Uladzislau Rezki" <urezki@...il.com>,
        "Michal Hocko" <mhocko@...nel.org>,
        "Dave Chinner" <david@...morbit.com>,
        "Christoph Hellwig" <hch@....de>, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, "LKML" <linux-kernel@...r.kernel.org>,
        "Ilya Dryomov" <idryomov@...il.com>,
        "Jeff Layton" <jlayton@...nel.org>,
        "Michal Hocko" <mhocko@...e.com>
Subject: Re: [PATCH v2 2/4] mm/vmalloc: add support for __GFP_NOFAIL

On Wed, 24 Nov 2021, Andrew Morton wrote:
> 
> I added GFP_NOFAIL back in the mesozoic era because quite a lot of
> sites were doing open-coded try-forever loops.  I thought "hey, they
> shouldn't be doing that in the first place, but let's at least
> centralize the concept to reduce code size, code duplication and so
> it's something we can now grep for".  But longer term, all GFP_NOFAIL
> sites should be reworked to no longer need to do the retry-forever
> thing.  In retrospect, this bright idea of mine seems to have added
> license for more sites to use retry-forever.  Sigh.

One of the costs of not having GFP_NOFAIL (or similar) is lots of
untested failure-path code.

When does an allocation that is allowed to retry and reclaim ever fail
anyway? I think the answer is "only when it has been killed by the oom
killer".  That of course cannot happen to kernel threads, so maybe
kernel threads should never need GFP_NOFAIL??

I'm not sure the above is 100%, but I do think that is the sort of
semantic that we want.  We want to know what kmalloc failure *means*.
We also need well defined and documented strategies to handle it.
mempools are one such strategy, but not always suitable.
preallocating can also be useful but can be clumsy to implement.  Maybe
we should support a process preallocating a bunch of pages which can
only be used by the process - and are auto-freed when the process
returns to user-space.  That might allow the "error paths" to be simple
and early, and subsequent allocations that were GFP_USEPREALLOC would be
safe.

i.e. we need a plan for how to rework all those no-fail call-sites.

NeilBrown