Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Biju Das]

Hi All,

I get below warning with today's next. Can you please suggest how to fix this warning?


[   13.122280] systemd[1]: File System Check on Root Device was skipped because of an unmet condition check (ConditionPathIsReadWrite=!/).
[   13.142562] ------------[ cut here ]------------
[   13.147308] Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp: 0x100dc0 (GFP_USER|__GFP_ZERO). Fix your code!
[   13.158526] WARNING: mm/vmalloc.c:3937 at vmalloc_fix_flags+0x9c/0xac, CPU#1: systemd/1
[   13.166576] Modules linked in: backlight ipv6
[   13.170983] CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc6-next-20251118-gcc318393a5df #175 PREEMPT
[   13.181082] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT)
[   13.187641] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   13.194675] pc : vmalloc_fix_flags+0x9c/0xac
[   13.194705] lr : vmalloc_fix_flags+0x9c/0xac
[   13.194715] sp : ffff8000828fbab0
[   13.194719] x29: ffff8000828fbad0 x28: 0000000000000000 x27: 0000000000000000
[   13.194734] x26: 0000000000000000 x25: 0000000000000000 x24: 000000000000000f
[   13.194746] x23: 0000ffffcc595b58 x22: 0000000000001000 x21: 0000000000100cc0
[   13.194757] x20: ffff8000801d7af0 x19: 0000000000001000 x18: 0000000000000006
[   13.194768] x17: 0000000000000000 x16: 0000000000000000 x15: 006c326703000000
[   13.194779] x14: 00000000000001da x13: 00000000000001da x12: 0000000000000000
[   13.194790] x11: 00000000000000c0 x10: 0000000000000ac0 x9 : ffff8000828fb920
[   13.194802] x8 : ffff00000aca8b20 x7 : 00000000021cb08a x6 : 0000000000000186
[   13.194813] x5 : 000000009d17f2f7 x4 : ffff800037e00000 x3 : 0000000000000010
[   13.194824] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00000aca8000
[   13.194836] Call trace:
[   13.194842]  vmalloc_fix_flags+0x9c/0xac (P)
[   13.194855]  __vmalloc_noprof+0x60/0x74
[   13.194865]  bpf_prog_alloc_no_stats+0x44/0x218
[   13.194879]  bpf_prog_alloc+0x28/0xec
[   13.194888]  bpf_prog_load+0x168/0xcdc
[   13.194899]  __sys_bpf+0x814/0x211c
[   13.194907]  __arm64_sys_bpf+0x24/0x40
[   13.194916]  invoke_syscall+0x48/0x104
[   13.194927]  el0_svc_common.constprop.0+0x40/0xe0
[   13.194935]  do_el0_svc+0x1c/0x28
[   13.194943]  el0_svc+0x34/0x108
[   13.194955]  el0t_64_sync_handler+0xa0/0xf0
[   13.194964]  el0t_64_sync+0x198/0x19c
[   13.194975] ---[ end trace 0000000000000000 ]---
[   13.328233] fuse: init (API version 7.45)
[   13.339395] systemd[1]: Starting Journal Service...


Cheers,
Biju

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Vishal Moola (Oracle)]

On Tue, Nov 18, 2025 at 04:14:01PM +0000, Biju Das wrote:
> Hi All,
> 
> I get below warning with today's next. Can you please suggest how to fix this warning?

Thanks Biju. This has been fixed and will be in whenever Andrews tree
gets merged again.

> 
> [   13.122280] systemd[1]: File System Check on Root Device was skipped because of an unmet condition check (ConditionPathIsReadWrite=!/).
> [   13.142562] ------------[ cut here ]------------
> [   13.147308] Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp: 0x100dc0 (GFP_USER|__GFP_ZERO). Fix your code!
> [   13.158526] WARNING: mm/vmalloc.c:3937 at vmalloc_fix_flags+0x9c/0xac, CPU#1: systemd/1
> [   13.166576] Modules linked in: backlight ipv6
> [   13.170983] CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc6-next-20251118-gcc318393a5df #175 PREEMPT
> [   13.181082] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT)
> [   13.187641] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [   13.194675] pc : vmalloc_fix_flags+0x9c/0xac
> [   13.194705] lr : vmalloc_fix_flags+0x9c/0xac
> [   13.194715] sp : ffff8000828fbab0
> [   13.194719] x29: ffff8000828fbad0 x28: 0000000000000000 x27: 0000000000000000
> [   13.194734] x26: 0000000000000000 x25: 0000000000000000 x24: 000000000000000f
> [   13.194746] x23: 0000ffffcc595b58 x22: 0000000000001000 x21: 0000000000100cc0
> [   13.194757] x20: ffff8000801d7af0 x19: 0000000000001000 x18: 0000000000000006
> [   13.194768] x17: 0000000000000000 x16: 0000000000000000 x15: 006c326703000000
> [   13.194779] x14: 00000000000001da x13: 00000000000001da x12: 0000000000000000
> [   13.194790] x11: 00000000000000c0 x10: 0000000000000ac0 x9 : ffff8000828fb920
> [   13.194802] x8 : ffff00000aca8b20 x7 : 00000000021cb08a x6 : 0000000000000186
> [   13.194813] x5 : 000000009d17f2f7 x4 : ffff800037e00000 x3 : 0000000000000010
> [   13.194824] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00000aca8000
> [   13.194836] Call trace:
> [   13.194842]  vmalloc_fix_flags+0x9c/0xac (P)
> [   13.194855]  __vmalloc_noprof+0x60/0x74
> [   13.194865]  bpf_prog_alloc_no_stats+0x44/0x218
> [   13.194879]  bpf_prog_alloc+0x28/0xec
> [   13.194888]  bpf_prog_load+0x168/0xcdc
> [   13.194899]  __sys_bpf+0x814/0x211c
> [   13.194907]  __arm64_sys_bpf+0x24/0x40
> [   13.194916]  invoke_syscall+0x48/0x104
> [   13.194927]  el0_svc_common.constprop.0+0x40/0xe0
> [   13.194935]  do_el0_svc+0x1c/0x28
> [   13.194943]  el0_svc+0x34/0x108
> [   13.194955]  el0t_64_sync_handler+0xa0/0xf0
> [   13.194964]  el0t_64_sync+0x198/0x19c
> [   13.194975] ---[ end trace 0000000000000000 ]---
> [   13.328233] fuse: init (API version 7.45)
> [   13.339395] systemd[1]: Starting Journal Service...
> 
> 
> Cheers,
> Biju

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Matthew Wilcox]

On Tue, Nov 18, 2025 at 09:07:56AM -0800, Vishal Moola (Oracle) wrote:
> On Tue, Nov 18, 2025 at 04:14:01PM +0000, Biju Das wrote:
> > Hi All,
> > 
> > I get below warning with today's next. Can you please suggest how to fix this warning?
> 
> Thanks Biju. This has been fixed and will be in whenever Andrews tree
> gets merged again.

I see:

Unexpected gfp: 0x1000000 (__GFP_NOLOCKDEP). Fixing up to gfp: 0x2dc0 (GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN). Fix your code!

I suspect __GFP_NOLOCKDEP should also be permitted by vmalloc.

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Vishal Moola (Oracle)]

On Tue, Nov 18, 2025 at 07:57:29PM +0000, Matthew Wilcox wrote:
> On Tue, Nov 18, 2025 at 09:07:56AM -0800, Vishal Moola (Oracle) wrote:
> > On Tue, Nov 18, 2025 at 04:14:01PM +0000, Biju Das wrote:
> > > Hi All,
> > > 
> > > I get below warning with today's next. Can you please suggest how to fix this warning?
> > 
> > Thanks Biju. This has been fixed and will be in whenever Andrews tree
> > gets merged again.
> 
> I see:
> 
> Unexpected gfp: 0x1000000 (__GFP_NOLOCKDEP). Fixing up to gfp: 0x2dc0 (GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN). Fix your code!
> 
> I suspect __GFP_NOLOCKDEP should also be permitted by vmalloc.

As far as I can tell, theres only 1 caller of this.
Christoph started using vmalloc for this xfs call in commit
e2874632a621 ("xfs: use vmalloc instead of vm_map_area for buffer backing memory").

Looks like xfs uses the flag to prevent false positives. Do
we want to continue this? If so, I'll send a patch adding the flag to
the whitelist.

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Christoph Hellwig]

On Wed, Nov 19, 2025 at 10:55:21AM -0800, Vishal Moola (Oracle) wrote:
> > Unexpected gfp: 0x1000000 (__GFP_NOLOCKDEP). Fixing up to gfp: 0x2dc0 (GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN). Fix your code!
> > 
> > I suspect __GFP_NOLOCKDEP should also be permitted by vmalloc.
> 
> As far as I can tell, theres only 1 caller of this.
> Christoph started using vmalloc for this xfs call in commit
> e2874632a621 ("xfs: use vmalloc instead of vm_map_area for buffer backing memory").
> 
> Looks like xfs uses the flag to prevent false positives. Do
> we want to continue this? If so, I'll send a patch adding the flag to
> the whitelist.

I'm not a fan of __GFP_NOLOCKDEP, but it is a valid hint for the
allocator, so it should be supported.

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Andrew Morton]

On Wed, 19 Nov 2025 17:03:02 -0800 SeongJae Park <sj@kernel.org> wrote:

> On Mon, 17 Nov 2025 09:35:26 -0800 "Vishal Moola (Oracle)" <vishal.moola@gmail.com> wrote:
> 
> > We should do a better job at enforcing gfp flags for vmalloc. Right now, we
> > have a kernel-doc for __vmalloc_node_range(), and hope callers pass in
> > supported flags. If a caller were to pass in an unsupported flag, we may
> > BUG, silently clear it, or completely ignore it.
> > 
> > If we are more proactive about enforcing gfp flags, we can making sure
> > callers know when they may be asking for unsupported behavior.
> > 
> > This patchset lets vmalloc control the incoming gfp flags, and cleans up
> > some hard to read gfp code.
> 
> For the series,
> 
> Acked-by: SeongJae Park <sj@kernel.org>

Thanks.

> > 
> > ---
> > Linked rfc [1] and rfc v2[2] for convenience.
> > 
> > Patch v2 -> v3:
> >   Only changes the whitelist mask and comment in patch 1:
> 
> I'd suggest s/whitelist/allow-list/.

Yeah, it's the modern way.  But this was below the ^---$ separator so
it went away anyway.

Re: [PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[SeongJae Park]

On Mon, 17 Nov 2025 09:35:26 -0800 "Vishal Moola (Oracle)" <vishal.moola@gmail.com> wrote:

> We should do a better job at enforcing gfp flags for vmalloc. Right now, we
> have a kernel-doc for __vmalloc_node_range(), and hope callers pass in
> supported flags. If a caller were to pass in an unsupported flag, we may
> BUG, silently clear it, or completely ignore it.
> 
> If we are more proactive about enforcing gfp flags, we can making sure
> callers know when they may be asking for unsupported behavior.
> 
> This patchset lets vmalloc control the incoming gfp flags, and cleans up
> some hard to read gfp code.

For the series,

Acked-by: SeongJae Park <sj@kernel.org>

> 
> ---
> Linked rfc [1] and rfc v2[2] for convenience.
> 
> Patch v2 -> v3:
>   Only changes the whitelist mask and comment in patch 1:

I'd suggest s/whitelist/allow-list/.


Thanks,
SJ

[...]

[PATCH v3 0/4] make vmalloc gfp flags usage more apparent

[Vishal Moola (Oracle)]

We should do a better job at enforcing gfp flags for vmalloc. Right now, we
have a kernel-doc for __vmalloc_node_range(), and hope callers pass in
supported flags. If a caller were to pass in an unsupported flag, we may
BUG, silently clear it, or completely ignore it.

If we are more proactive about enforcing gfp flags, we can making sure
callers know when they may be asking for unsupported behavior.

This patchset lets vmalloc control the incoming gfp flags, and cleans up
some hard to read gfp code.

---
Linked rfc [1] and rfc v2[2] for convenience.

Patch v2 -> v3:
  Only changes the whitelist mask and comment in patch 1:
  - Replace __GFP_HARDWALL with GFP_USER
  - Add GFP_KERNEL_ACCOUNT[4]
  - Add GFP_NOFS and GFP_NOIO just so all supported flags are explicitly
    listed in the mask.

v2:
  - Add __GFP_HARDWALL[3] for bpf and drm users.
  - cc BPF mailing list

RFC -> PATCH:
  - Collected review tags (Patches 1 & 4)
  - Add unlikely keyword to help the compiler
  - Replace pr_warn() with WARN(1)

RFC v2:
  - Whitelist supported gfp flags instead of blacklisting the unsupported
  - Move the flags check up to the only exported functions that accept
    flags:
	__vmalloc_noprof() and vmalloc_huge_node_prof()

[1] https://lore.kernel.org/linux-mm/20251030164330.44995-1-vishal.moola@gmail.com/
[2] https://lore.kernel.org/linux-mm/20251103190429.104747-1-vishal.moola@gmail.com/
[3] https://lore.kernel.org/linux-mm/20251110160457.61791-1-vishal.moola@gmail.com/T/#me8b548520ce9c81a5099c00abe53dd248c16eae7
[4] https://lore.kernel.org/linux-mm/69158bb1.a70a0220.3124cb.001e.GAE@google.com/

Vishal Moola (Oracle) (4):
  mm/vmalloc: warn on invalid vmalloc gfp flags
  mm/vmalloc: Add a helper to optimize vmalloc allocation gfps
  mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages()
  mm/vmalloc: cleanup gfp flag use in new_vmap_block()

 mm/vmalloc.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 42 insertions(+), 8 deletions(-)

-- 
2.51.1