All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Graf <tgraf@suug.ch>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Manfred Spraul <manfred@colorfullife.com>,
	guillaume.knispel@supersonicimagine.com,
	Linux API <linux-api@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 3/6] lib/bucket_locks: use kvmalloc_array()
Date: Tue, 29 May 2018 15:46:25 -0500	[thread overview]
Message-ID: <CA+55aFxoC0+hKBQ_TmbXM_X60fnP8JKC3aVvGc=8bKh2oxL12g@mail.gmail.com> (raw)
In-Reply-To: <20180529145106.GV27180@dhcp22.suse.cz>

On Tue, May 29, 2018 at 9:51 AM Michal Hocko <mhocko@kernel.org> wrote:

> In other words, what about the following?

> +       WARN_ON_ONCE((flags & (__GFP_FS|__GFP_IO)) !=
(__GFP_FS|__GFP_IO));

I  still don't understand the point of this warning.

It's only stupid. It basically says "this function is garbage, so let me
warn about the fact that I'm a moron".

If we all needed to warn about ourselves being morons, there would be a
hell of a lot of big blinking signs everywhere.

And the *ONLY* thing that warning has ever caused is  just stupid code that
does

     if (flags == GFP_KERNEL)
         .. do kvmalloc ..
     else
         .. do kmalloc() ..

which is a *STUPID* pattern.

In other words, the WARN_ON() is bogus garbage. It's bogus exactly because
NOBODY CARES and all everybody will ever do is to just avoid it by writing
worse code.

The whole and ONLY point of "kvmalloc()" and friends is to make it easy to
write code and _not_ have those idiotic "let's do kmalloc or kvmalloc
depending on the phase of the moon" garbage. So the warning has literally
destroyed the only value that function has!

> +       if (!gfpflags_allow_blocking(flags))
> +               return NULL;
> +

And no. Now all the code *above* this check is just wrong. All the code
that modifies the gfp_flags with the intention of falling back on vmalloc()
is just wrong, since we're not falling back on vmalloc any more.

So I really think the semantics should be simple:

  - if we don't allow GFP_KERNEL, then the code becomes just "kmalloc()",
since there is no valid fallback to vmalloc. vmalloc does GFP_KERNEL.

  - otherwise, we do what we used to do (except now the warning is gone,
because we already handled the case it warned about).

Nothing else. No stupid other cases. The *only* thing that function should
ask itself is "can I fall back on vmalloc or not", and if it can't then it
should just be a kmalloc.

Because otherwise we'll continue to have people that just check in the
caller instead.

         Linus

  reply	other threads:[~2018-05-29 20:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24 21:11 [PATCH -next 0/6] rhashtable: guarantee first allocation Davidlohr Bueso
2018-05-24 21:11 ` [PATCH 1/6] lib/rhashtable: convert param sanitations to WARN_ON Davidlohr Bueso
2018-05-28  9:40   ` Herbert Xu
2018-05-28 13:12     ` Davidlohr Bueso
2018-05-28 15:54       ` Herbert Xu
2018-05-28 15:51         ` Davidlohr Bueso
2018-05-24 21:11 ` [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation Davidlohr Bueso
2018-05-25  3:26   ` Davidlohr Bueso
2018-05-28  9:49   ` Herbert Xu
2018-05-29 17:03     ` Davidlohr Bueso
2018-05-29 18:04       ` Herbert Xu
2018-05-29 17:59         ` Davidlohr Bueso
2018-05-29 18:27           ` Herbert Xu
2018-05-30 14:29             ` Davidlohr Bueso
2018-05-28 10:02   ` Herbert Xu
2018-05-29 16:42     ` Davidlohr Bueso
2018-05-29 18:03       ` Herbert Xu
2018-05-29 17:55         ` Davidlohr Bueso
2018-05-29 18:15           ` Herbert Xu
2018-05-29 18:05             ` Davidlohr Bueso
2018-05-24 21:11 ` [PATCH 3/6] lib/bucket_locks: use kvmalloc_array() Davidlohr Bueso
2018-05-24 21:37   ` Linus Torvalds
2018-05-29 14:43     ` Michal Hocko
2018-05-29 14:51       ` Michal Hocko
2018-05-29 20:46         ` Linus Torvalds [this message]
2018-05-30  7:42           ` Michal Hocko
2018-05-31 15:01             ` Linus Torvalds
2018-05-31 15:29               ` Michal Hocko
2018-05-24 21:11 ` [PATCH 4/6] ipc: get rid of ids->tables_initialized hack Davidlohr Bueso
2018-05-24 21:11 ` [PATCH 5/6] ipc: simplify ipc initialization Davidlohr Bueso
2018-05-24 21:11 ` [PATCH 6/6] lib/test_rhashtable: rhashtable_init() can no longer fail Davidlohr Bueso
2018-05-24 21:41 ` [PATCH -next 0/6] rhashtable: guarantee first allocation Linus Torvalds
2018-05-25  3:34   ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFxoC0+hKBQ_TmbXM_X60fnP8JKC3aVvGc=8bKh2oxL12g@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=dbueso@suse.de \
    --cc=guillaume.knispel@supersonicimagine.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mhocko@kernel.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.