From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Leo Yan <leo.yan@arm.com>, Mikel Rychliski <mikel@mikelr.com>,
Viktor Malik <vmalik@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] probes: Fixes for v6.12-rc4-2
Date: Fri, 25 Oct 2024 12:09:48 +0900 [thread overview]
Message-ID: <20241025120948.916e8c099fee7200e32ae617@kernel.org> (raw)
In-Reply-To: <CAHk-=whO+vSH+XVRio8byJU8idAWES0SPGVZ7KAVdc4qrV0VUA@mail.gmail.com>
On Thu, 24 Oct 2024 14:05:08 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 23 Oct 2024 at 07:36, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > - objpool: Fix choosing allocation for percpu slots
> >
> > Fixes to allocate objpool's percpu slots correctly according to the
> > GFP flag. It checks whether "any bit" in GFP_ATOMIC is set to choose
> > the vmalloc source, but it should check "all bits" in GFP_ATOMIC flag
> > is set, because GFP_ATOMIC is a combined flag.
>
> So the old code was buggy, but I don't think the new code is wonderful either.
Agreed.
>
> For example, it does not recognized GFP_NOWAIT, which has very similar
> characteristics to GFP_ATOMIC (it's basically the same thing as
> GFP_ATOMIC, but without the "try to allocate urgently", and with an
> added "don't warn on failure" as a result).
>
> So what I think that code *should* test for is "can I sleep".
>
> Which is indicated by __GFP_IO or __GFP_FS (and, I guess also
> __GFP_DIRECT_RECLAIM).
This code is for switching __vmalloc_node() to kmalloc_node() based on
GFP_ATOMIC, because __vmalloc_node() does not support GFP_ATOMIC.
---
/**
* __vmalloc_node_range - allocate virtually contiguous memory
...
*
* Allocate enough pages to cover @size from the page level
* allocator with @gfp_mask flags. Please note that the full set of gfp
* flags are not supported. GFP_KERNEL, GFP_NOFS and GFP_NOIO are all
* supported.
---
(BTW, the above kerneldoc is a bit outdated, because the function name
has been changed to `__vmalloc_node_range_noprof()`)
As above said, it supports GFP_KENEL & GFP_NOFS & GFP_NOIO, which
means __GFP_RECLAIM (= ___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM) is
required.
Since GFP_ATOMIC is __GFP_HIGH | __GFP_KSWAPD_RECLAIM, the difference
is ___GFP_DIRECT_RECLAIM is not set if GFP_ATOMIC is specified.
But I don't want to touch such bitflags deeper. What about simply
masking with GFP_ATOMIC | GFP_KERNEL? I mean
if ((gfp & (GFP_ATOMIC | GFP_KERNEL)) == GFP_ATOMIC)
/* use kmalloc_node() because vmalloc does not support GFP_ATOMIC */
slot = kmalloc_node(...)
else
slot = __vmalloc_node(...)
Or, simply failback to kmalloc_node() if __vmalloc_node() fails.
(I think this is more robust.)
slot = __vmalloc_node(...)
if (!slot)
slot = kmalloc_node(...)
(Note that slot is freed by kvfree() so either works)
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2024-10-25 3:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 14:36 [GIT PULL] probes: Fixes for v6.12-rc4-2 Masami Hiramatsu
2024-10-24 21:05 ` Linus Torvalds
2024-10-25 3:09 ` Masami Hiramatsu [this message]
2024-10-24 21:29 ` pr-tracker-bot
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=20241025120948.916e8c099fee7200e32ae617@kernel.org \
--to=mhiramat@kernel.org \
--cc=leo.yan@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikel@mikelr.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=vmalik@redhat.com \
/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.