linux-kernel - Re: [PATCH] mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags

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: <CA+55aFwaYEn8rA=-8hi1v8wWiLGJJsvkuEvBOxgvnmfUBfg4Vg@mail.gmail.com>
Date:   Sat, 2 Jun 2018 09:43:56 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, tom@...ntonium.net,
        linux-mm <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm: kvmalloc does not fallback to vmalloc for
 incompatible gfp flags

On Fri, Jun 1, 2018 at 4:53 AM Michal Hocko <mhocko@...nel.org> wrote:
>
> for more context. Linus has pointed out [1] that our (well mine)
> insisting on GFP_KERNEL compatible gfp flags for kvmalloc* can actually
> lead to a worse code because people will work around the restriction.
> So this patch allows kvmalloc to be more permissive and silently skip
> vmalloc path for incompatible gfp flags.

Ack.

> This will not help my original
> plan to enforce people to think about GFP_NOFS usage more deeply but
> I can live with that obviously...

Is it NOFS in particular you care about? The only reason for that
should be the whole "don't recurse", and I think the naming is
historical and slightly odd.

It was historically just about allocations that were in the writeout
path for a block layer or filesystem - and the name made sense in that
context. These days, I think it's just shorthand for "you can do
simple direct reclaim from the mm itself, but you can't  block or call
anything else".

So I think the name and the semantics are a bit unclear, but it's
obviously still useful.

It's entirely possible that direct reclaim should never do any of the
more complicated callback cases anyway, but we'd still need the whole
"don't wait for the complex case" logic to avoid deadlocks.

           Linus