[v2] make vmalloc gfp flags usage more apparent

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

Posted by Vishal Moola (Oracle) 2 months, 3 weeks ago

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.

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

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 | 48 ++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 8 deletions(-)

-- 
2.51.1

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

Posted by Andrew Morton 2 months, 3 weeks ago

On Wed, 12 Nov 2025 10:58:29 -0800 "Vishal Moola (Oracle)" <vishal.moola@gmail.com> wrote:

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

v1->v2 diff:

--- a/mm/vmalloc.c~b
+++ a/mm/vmalloc.c
@@ -3922,10 +3922,12 @@ fail:
 /*
  * See __vmalloc_node_range() for a clear list of supported vmalloc flags.
  * This gfp lists all flags currently passed through vmalloc. Currently,
- * __GFP_ZERO is used by BFP and __GFP_NORETRY is used by percpu.
+ * __GFP_ZERO is used by BPF and __GFP_NORETRY is used by percpu. Both drm
+ * and BPF also use GFP_USER, which is GFP_KERNEL | __GFP_HARDWALL.
  */
 #define GFP_VMALLOC_SUPPORTED (GFP_KERNEL | GFP_ATOMIC | GFP_NOWAIT |\
-				__GFP_NOFAIL |  __GFP_ZERO | __GFP_NORETRY)
+				__GFP_NOFAIL |  __GFP_ZERO | __GFP_NORETRY |\
+				__GFP_HARDWALL)
 
 static gfp_t vmalloc_fix_flags(gfp_t flags)
 {
_

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

Posted by Baolin Wang 2 months, 3 weeks ago

Hi,

On 2025/11/13 02:58, Vishal Moola (Oracle) 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.
> 
> ---
> Linked rfc [1] and rfc v2[2] for convenience.

Just FYI, I hit this warning when booting today's mm-new branch.

[    1.238451] ------------[ cut here ]------------
[    1.238453] Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to 
gfp: 0xdc0 (GFP_KERNEL|__GFP_ZERO). Fix your code!
[    1.249347] WARNING: CPU: 27 PID: 338 at mm/vmalloc.c:3937 
__vmalloc_noprof+0x74/0x80
[    1.249352] Modules linked in:
[    1.249354] CPU: 27 UID: 0 PID: 338 Comm: (journald) Not tainted 
6.18.0-rc5+ #55 PREEMPT(none)
[    1.249357] RIP: 0010:__vmalloc_noprof+0x74/0x80
[    1.249359] Code: 00 5d e9 6f f8 ff ff 89 d1 49 89 e0 48 8d 54 24 04 
89 74 24 04 81 e1 e0 ad 11 00 48 c7 c7 68 b0 75 82 89 0c 24 e8 7c bf ce 
ff <0f> 0b 8b 14 24 eb ab e8 f0 61 a5 00 90
  90 90 90 90 90 90 90 90 90
[    1.249360] RSP: 0018:ffffc90000bebe08 EFLAGS: 00010286
[    1.249362] RAX: 0000000000000000 RBX: 0000000000001000 RCX: 
ffffffff82fdee68
[    1.249363] RDX: 000000000000001b RSI: 0000000000000000 RDI: 
ffffffff82a5ee60
[    1.249364] RBP: 0000000000001000 R08: 0000000000000000 R09: 
ffffc90000bebcb8
[    1.249364] R10: ffffc90000bebcb0 R11: ffffffff8315eea8 R12: 
ffff88810aac98c0
[    1.249365] R13: 0000000000000000 R14: ffffffff8141abe0 R15: 
fffffffffffffff3
[    1.249368] FS:  00007fbc9436ee80(0000) GS:ffff88bec00e1000(0000) 
knlGS:0000000000000000
[    1.249370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.249371] CR2: 0000562248eda010 CR3: 00000001028a8005 CR4: 
0000000000770ef0
[    1.249371] PKRU: 55555554
[    1.249372] Call Trace:
[    1.249373]  <TASK>
[    1.249374]  bpf_prog_alloc_no_stats+0x37/0x250
[    1.249377]  ? __pfx_seccomp_check_filter+0x10/0x10
[    1.249379]  bpf_prog_alloc+0x1a/0xa0
[    1.249381]  bpf_prog_create_from_user+0x51/0x130
[    1.249385]  seccomp_set_mode_filter+0x117/0x410
[    1.249387]  do_syscall_64+0x5b/0xda0
[    1.249390]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[    1.249392] RIP: 0033:0x7fbc94f4c9cd

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

Posted by Vishal Moola (Oracle) 2 months, 3 weeks ago

On Thu, Nov 13, 2025 at 11:48:05AM +0800, Baolin Wang wrote:
> Hi,
> 
> On 2025/11/13 02:58, Vishal Moola (Oracle) 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.
> > 
> > ---
> > Linked rfc [1] and rfc v2[2] for convenience.
> 
> Just FYI, I hit this warning when booting today's mm-new branch.
>
> [    1.238451] ------------[ cut here ]------------
> [    1.238453] Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp:

Thanks. I'll send an updated version that catches this next week. In the
meantime, do let me know if you find any more warnings for other gfp
flags.

> 0xdc0 (GFP_KERNEL|__GFP_ZERO). Fix your code!
> [    1.249347] WARNING: CPU: 27 PID: 338 at mm/vmalloc.c:3937
> __vmalloc_noprof+0x74/0x80
> [    1.249352] Modules linked in:
> [    1.249354] CPU: 27 UID: 0 PID: 338 Comm: (journald) Not tainted
> 6.18.0-rc5+ #55 PREEMPT(none)
> [    1.249357] RIP: 0010:__vmalloc_noprof+0x74/0x80
> [    1.249359] Code: 00 5d e9 6f f8 ff ff 89 d1 49 89 e0 48 8d 54 24 04 89
> 74 24 04 81 e1 e0 ad 11 00 48 c7 c7 68 b0 75 82 89 0c 24 e8 7c bf ce ff <0f>
> 0b 8b 14 24 eb ab e8 f0 61 a5 00 90
>  90 90 90 90 90 90 90 90 90
> [    1.249360] RSP: 0018:ffffc90000bebe08 EFLAGS: 00010286
> [    1.249362] RAX: 0000000000000000 RBX: 0000000000001000 RCX:
> ffffffff82fdee68
> [    1.249363] RDX: 000000000000001b RSI: 0000000000000000 RDI:
> ffffffff82a5ee60
> [    1.249364] RBP: 0000000000001000 R08: 0000000000000000 R09:
> ffffc90000bebcb8
> [    1.249364] R10: ffffc90000bebcb0 R11: ffffffff8315eea8 R12:
> ffff88810aac98c0
> [    1.249365] R13: 0000000000000000 R14: ffffffff8141abe0 R15:
> fffffffffffffff3
> [    1.249368] FS:  00007fbc9436ee80(0000) GS:ffff88bec00e1000(0000)
> knlGS:0000000000000000
> [    1.249370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    1.249371] CR2: 0000562248eda010 CR3: 00000001028a8005 CR4:
> 0000000000770ef0
> [    1.249371] PKRU: 55555554
> [    1.249372] Call Trace:
> [    1.249373]  <TASK>
> [    1.249374]  bpf_prog_alloc_no_stats+0x37/0x250
> [    1.249377]  ? __pfx_seccomp_check_filter+0x10/0x10
> [    1.249379]  bpf_prog_alloc+0x1a/0xa0
> [    1.249381]  bpf_prog_create_from_user+0x51/0x130
> [    1.249385]  seccomp_set_mode_filter+0x117/0x410
> [    1.249387]  do_syscall_64+0x5b/0xda0
> [    1.249390]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [    1.249392] RIP: 0033:0x7fbc94f4c9cd
>

[syzbot ci] Re: make vmalloc gfp flags usage more apparent

Posted by syzbot ci 2 months, 3 weeks ago

syzbot ci has tested the following series

[v2] make vmalloc gfp flags usage more apparent
https://lore.kernel.org/all/20251112185834.32487-1-vishal.moola@gmail.com
* [PATCH v2 1/4] mm/vmalloc: warn on invalid vmalloc gfp flags
* [PATCH v2 2/4] mm/vmalloc: Add a helper to optimize vmalloc allocation gfps
* [PATCH v2 3/4] mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages()
* [PATCH v2 4/4] mm/vmalloc: cleanup gfp flag use in new_vmap_block()

and found the following issue:
WARNING: kmalloc bug in bpf_prog_alloc_no_stats

Full report is available here:
https://ci.syzbot.org/series/46d6cb1a-188d-4ff5-8fab-9c58465d74d3

***

WARNING: kmalloc bug in bpf_prog_alloc_no_stats

tree:      linux-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base:      b179ce312bafcb8c68dc718e015aee79b7939ff0
arch:      amd64
compiler:  Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
config:    https://ci.syzbot.org/builds/3449e2a5-35e0-4eac-86c6-97ca0ec741d7/config

------------[ cut here ]------------
Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp: 0xdc0 (GFP_KERNEL|__GFP_ZERO). Fix your code!
WARNING: mm/vmalloc.c:3938 at vmalloc_fix_flags+0x9c/0xe0, CPU#1: syz-executor/6079
Modules linked in:
CPU: 1 UID: 0 PID: 6079 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:vmalloc_fix_flags+0x9c/0xe0
Code: 81 e6 1f 52 ee ff 89 74 24 30 81 e3 e0 ad 11 00 89 5c 24 20 90 48 c7 c7 40 c3 76 8b 4c 89 fa 89 d9 4d 89 f0 e8 a5 a1 6c ff 90 <0f> 0b 90 90 8b 44 24 20 48 c7 04 24 0e 36 e0 45 4b c7 04 2c 00 00
RSP: 0018:ffffc90005557b00 EFLAGS: 00010246
RAX: a6bff5ae8e950700 RBX: 0000000000000dc0 RCX: ffff888173b29d40
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002
RBP: ffffc90005557b98 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1bba6ec R12: 1ffff92000aaaf60
R13: dffffc0000000000 R14: ffffc90005557b20 R15: ffffc90005557b30
FS:  000055557c070500(0000) GS:ffff8882a9ec0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f86f6df0000 CR3: 0000000113d64000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 __vmalloc_noprof+0xf2/0x120
 bpf_prog_alloc_no_stats+0x4a/0x4d0
 bpf_prog_alloc+0x3c/0x1a0
 bpf_prog_create_from_user+0xa7/0x440
 do_seccomp+0x7b1/0xd90
 __se_sys_prctl+0xc3c/0x1830
 do_syscall_64+0xfa/0xfa0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fcbe2f90b0d
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 18 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 9d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 1b 48 8b 54 24 18 64 48 2b 14 25 28 00 00 00
RSP: 002b:00007ffed4000b80 EFLAGS: 00000246 ORIG_RAX: 000000000000009d
RAX: ffffffffffffffda RBX: 00007fcbe302cf80 RCX: 00007fcbe2f90b0d
RDX: 00007ffed4000be0 RSI: 0000000000000002 RDI: 0000000000000016
RBP: 00007ffed4000bf0 R08: 0000000000000006 R09: 0000000000000071
R10: 0000000000000071 R11: 0000000000000246 R12: 000000000000006d
R13: 00007ffed4001018 R14: 00007ffed4001298 R15: 0000000000000000
 </TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

Re: [syzbot ci] Re: make vmalloc gfp flags usage more apparent

Posted by Uladzislau Rezki 2 months, 3 weeks ago

On Wed, Nov 12, 2025 at 11:41:37PM -0800, syzbot ci wrote:
> syzbot ci has tested the following series
> 
> [v2] make vmalloc gfp flags usage more apparent
> https://lore.kernel.org/all/20251112185834.32487-1-vishal.moola@gmail.com
> * [PATCH v2 1/4] mm/vmalloc: warn on invalid vmalloc gfp flags
> * [PATCH v2 2/4] mm/vmalloc: Add a helper to optimize vmalloc allocation gfps
> * [PATCH v2 3/4] mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages()
> * [PATCH v2 4/4] mm/vmalloc: cleanup gfp flag use in new_vmap_block()
> 
> and found the following issue:
> WARNING: kmalloc bug in bpf_prog_alloc_no_stats
> 
> Full report is available here:
> https://ci.syzbot.org/series/46d6cb1a-188d-4ff5-8fab-9c58465d74d3
> 
> ***
> 
> WARNING: kmalloc bug in bpf_prog_alloc_no_stats
> 
> tree:      linux-next
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> base:      b179ce312bafcb8c68dc718e015aee79b7939ff0
> arch:      amd64
> compiler:  Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> config:    https://ci.syzbot.org/builds/3449e2a5-35e0-4eac-86c6-97ca0ec741d7/config
> 
> ------------[ cut here ]------------
> Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp: 0xdc0 (GFP_KERNEL|__GFP_ZERO). Fix your code!
> WARNING: mm/vmalloc.c:3938 at vmalloc_fix_flags+0x9c/0xe0, CPU#1: syz-executor/6079
> Modules linked in:
>
Again bpf :)

GFP_KERNEL_ACCOUNT? I saw there have been __GFP_HARDWALL added already,
IMO it is worth to replace it by "high level flag", which is GFP_USER.

--
Uladzislau Rezki

Re: [syzbot ci] Re: make vmalloc gfp flags usage more apparent

Posted by Vishal Moola (Oracle) 2 months, 3 weeks ago

On Thu, Nov 13, 2025 at 02:33:31PM +0100, Uladzislau Rezki wrote:
> On Wed, Nov 12, 2025 at 11:41:37PM -0800, syzbot ci wrote:
> > syzbot ci has tested the following series
> > 
> > [v2] make vmalloc gfp flags usage more apparent
> > https://lore.kernel.org/all/20251112185834.32487-1-vishal.moola@gmail.com
> > * [PATCH v2 1/4] mm/vmalloc: warn on invalid vmalloc gfp flags
> > * [PATCH v2 2/4] mm/vmalloc: Add a helper to optimize vmalloc allocation gfps
> > * [PATCH v2 3/4] mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages()
> > * [PATCH v2 4/4] mm/vmalloc: cleanup gfp flag use in new_vmap_block()
> > 
> > and found the following issue:
> > WARNING: kmalloc bug in bpf_prog_alloc_no_stats
> > 
> > Full report is available here:
> > https://ci.syzbot.org/series/46d6cb1a-188d-4ff5-8fab-9c58465d74d3
> > 
> > ***
> > 
> > WARNING: kmalloc bug in bpf_prog_alloc_no_stats
> > 
> > tree:      linux-next
> > URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> > base:      b179ce312bafcb8c68dc718e015aee79b7939ff0
> > arch:      amd64
> > compiler:  Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > config:    https://ci.syzbot.org/builds/3449e2a5-35e0-4eac-86c6-97ca0ec741d7/config
> > 
> > ------------[ cut here ]------------
> > Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp: 0xdc0 (GFP_KERNEL|__GFP_ZERO). Fix your code!
> > WARNING: mm/vmalloc.c:3938 at vmalloc_fix_flags+0x9c/0xe0, CPU#1: syz-executor/6079
> > Modules linked in:
> >
> Again bpf :)
> 
> GFP_KERNEL_ACCOUNT? I saw there have been __GFP_HARDWALL added already,
> IMO it is worth to replace it by "high level flag", which is GFP_USER.

Yeah I'll replace __GFP_HARDWALL with GFP_USER, and add
GFP_KERNEL_ACCOUNT. At this point I'll just add GFP_NOFS and GFP_NOIO
as well so its easier to understand the mask.

Re: [syzbot ci] Re: make vmalloc gfp flags usage more apparent

Posted by Uladzislau Rezki 2 months, 3 weeks ago

On Thu, Nov 13, 2025 at 08:48:41AM -0800, Vishal Moola (Oracle) wrote:
> On Thu, Nov 13, 2025 at 02:33:31PM +0100, Uladzislau Rezki wrote:
> > On Wed, Nov 12, 2025 at 11:41:37PM -0800, syzbot ci wrote:
> > > syzbot ci has tested the following series
> > > 
> > > [v2] make vmalloc gfp flags usage more apparent
> > > https://lore.kernel.org/all/20251112185834.32487-1-vishal.moola@gmail.com
> > > * [PATCH v2 1/4] mm/vmalloc: warn on invalid vmalloc gfp flags
> > > * [PATCH v2 2/4] mm/vmalloc: Add a helper to optimize vmalloc allocation gfps
> > > * [PATCH v2 3/4] mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages()
> > > * [PATCH v2 4/4] mm/vmalloc: cleanup gfp flag use in new_vmap_block()
> > > 
> > > and found the following issue:
> > > WARNING: kmalloc bug in bpf_prog_alloc_no_stats
> > > 
> > > Full report is available here:
> > > https://ci.syzbot.org/series/46d6cb1a-188d-4ff5-8fab-9c58465d74d3
> > > 
> > > ***
> > > 
> > > WARNING: kmalloc bug in bpf_prog_alloc_no_stats
> > > 
> > > tree:      linux-next
> > > URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> > > base:      b179ce312bafcb8c68dc718e015aee79b7939ff0
> > > arch:      amd64
> > > compiler:  Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > > config:    https://ci.syzbot.org/builds/3449e2a5-35e0-4eac-86c6-97ca0ec741d7/config
> > > 
> > > ------------[ cut here ]------------
> > > Unexpected gfp: 0x400000 (__GFP_ACCOUNT). Fixing up to gfp: 0xdc0 (GFP_KERNEL|__GFP_ZERO). Fix your code!
> > > WARNING: mm/vmalloc.c:3938 at vmalloc_fix_flags+0x9c/0xe0, CPU#1: syz-executor/6079
> > > Modules linked in:
> > >
> > Again bpf :)
> > 
> > GFP_KERNEL_ACCOUNT? I saw there have been __GFP_HARDWALL added already,
> > IMO it is worth to replace it by "high level flag", which is GFP_USER.
> 
> Yeah I'll replace __GFP_HARDWALL with GFP_USER, and add
> GFP_KERNEL_ACCOUNT. At this point I'll just add GFP_NOFS and GFP_NOIO
> as well so its easier to understand the mask.
>
Sounds good!

--
Uladzislau Rezki