From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, Uladzislau Rezki <urezki@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v2 0/4] make vmalloc gfp flags usage more apparent
Date: Thu, 13 Nov 2025 08:01:26 -0800 [thread overview]
Message-ID: <aRYA1shUhLeof8d8@fedora> (raw)
In-Reply-To: <e1d26f84-7ea2-46de-8ab9-31e49b485832@linux.alibaba.com>
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
>
next prev parent reply other threads:[~2025-11-13 16:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 18:58 [PATCH v2 0/4] make vmalloc gfp flags usage more apparent Vishal Moola (Oracle)
2025-11-12 18:58 ` [PATCH v2 1/4] mm/vmalloc: warn on invalid vmalloc gfp flags Vishal Moola (Oracle)
2025-11-12 18:58 ` [PATCH v2 2/4] mm/vmalloc: Add a helper to optimize vmalloc allocation gfps Vishal Moola (Oracle)
2025-11-12 18:58 ` [PATCH v2 3/4] mm/vmalloc: cleanup large_gfp in vm_area_alloc_pages() Vishal Moola (Oracle)
2025-11-12 18:58 ` [PATCH v2 4/4] mm/vmalloc: cleanup gfp flag use in new_vmap_block() Vishal Moola (Oracle)
2025-11-12 22:22 ` [PATCH v2 0/4] make vmalloc gfp flags usage more apparent Andrew Morton
2025-11-13 3:48 ` Baolin Wang
2025-11-13 16:01 ` Vishal Moola (Oracle) [this message]
2025-11-13 7:41 ` [syzbot ci] " syzbot ci
2025-11-13 13:33 ` Uladzislau Rezki
2025-11-13 16:48 ` Vishal Moola (Oracle)
2025-11-13 16:54 ` Uladzislau Rezki
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=aRYA1shUhLeof8d8@fedora \
--to=vishal.moola@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bpf@vger.kernel.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=urezki@gmail.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.