mm/vmalloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
From: David Heidelberg <david@ixit.cz>
Without WARN_ONCE, the logs get spammed immediately after the boot,
on devices as OnePlus 6T (Snapdragon 845).
Fixes: 7179b2256315 ("mm/vmalloc: warn on invalid vmalloc gfp flags")
Signed-off-by: David Heidelberg <david@ixit.cz>
---
I'm not 100% sure this is the right solution, but having WARN_ONCE or
rate limited warnings here helps a lot on devices as OnePlus 6 (sdm845).
Please let me know what you think.
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 49e0b68768d73..2a3ee17093d6e 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3934,8 +3934,8 @@ static gfp_t vmalloc_fix_flags(gfp_t flags)
gfp_t invalid_mask = flags & ~GFP_VMALLOC_SUPPORTED;
flags &= GFP_VMALLOC_SUPPORTED;
- WARN(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
- invalid_mask, &invalid_mask, flags, &flags);
+ WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
+ invalid_mask, &invalid_mask, flags, &flags);
return flags;
}
---
base-commit: 0c1c7a6a83feaf2cf182c52983ffe330ffb50280
change-id: 20251118-only-one-vmalloc-b8d997045791
Best regards,
--
David Heidelberg <david@ixit.cz>On Tue, Nov 18, 2025 at 01:05:57AM +0100, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Without WARN_ONCE, the logs get spammed immediately after the boot,
> on devices as OnePlus 6T (Snapdragon 845).
>
> Fixes: 7179b2256315 ("mm/vmalloc: warn on invalid vmalloc gfp flags")
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> I'm not 100% sure this is the right solution, but having WARN_ONCE or
> rate limited warnings here helps a lot on devices as OnePlus 6 (sdm845).
>
> Please let me know what you think.
> ---
> mm/vmalloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 49e0b68768d73..2a3ee17093d6e 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3934,8 +3934,8 @@ static gfp_t vmalloc_fix_flags(gfp_t flags)
> gfp_t invalid_mask = flags & ~GFP_VMALLOC_SUPPORTED;
>
> flags &= GFP_VMALLOC_SUPPORTED;
> - WARN(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
> - invalid_mask, &invalid_mask, flags, &flags);
> + WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
You accidentally deleted the comma here.
Once we've found all gfp the callers currently use, we should never be
hitting this warning, so ratelimiting won't matter. Either way is fine
by me though if you still want to fix and resend this.
> + invalid_mask, &invalid_mask, flags, &flags);
> return flags;
> }
>
>
> ---
> base-commit: 0c1c7a6a83feaf2cf182c52983ffe330ffb50280
> change-id: 20251118-only-one-vmalloc-b8d997045791
>
> Best regards,
> --
> David Heidelberg <david@ixit.cz>
>
>
On Mon, Nov 17, 2025 at 05:16:45PM -0800, Vishal Moola (Oracle) wrote:
> On Tue, Nov 18, 2025 at 01:05:57AM +0100, David Heidelberg via B4 Relay wrote:
> > From: David Heidelberg <david@ixit.cz>
> >
> > Without WARN_ONCE, the logs get spammed immediately after the boot,
> > on devices as OnePlus 6T (Snapdragon 845).
> >
> > Fixes: 7179b2256315 ("mm/vmalloc: warn on invalid vmalloc gfp flags")
> > Signed-off-by: David Heidelberg <david@ixit.cz>
> > ---
> > I'm not 100% sure this is the right solution, but having WARN_ONCE or
> > rate limited warnings here helps a lot on devices as OnePlus 6 (sdm845).
> >
> > Please let me know what you think.
> > ---
> > mm/vmalloc.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 49e0b68768d73..2a3ee17093d6e 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3934,8 +3934,8 @@ static gfp_t vmalloc_fix_flags(gfp_t flags)
> > gfp_t invalid_mask = flags & ~GFP_VMALLOC_SUPPORTED;
> >
> > flags &= GFP_VMALLOC_SUPPORTED;
> > - WARN(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
> > - invalid_mask, &invalid_mask, flags, &flags);
> > + WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
>
> You accidentally deleted the comma here.
>
> Once we've found all gfp the callers currently use, we should never be
> hitting this warning, so ratelimiting won't matter. Either way is fine
> by me though if you still want to fix and resend this.
>
IMO, it is worth to use ONCE variant to suppress spamming.
--
Uladzislau Rezki
Hi David,
kernel test robot noticed the following build errors:
[auto build test ERROR on 0c1c7a6a83feaf2cf182c52983ffe330ffb50280]
url: https://github.com/intel-lab-lkp/linux/commits/David-Heidelberg-via-B4-Relay/mm-vmalloc-warn-only-once-when-vmalloc-detect-invalid-gfp-flags/20251118-080722
base: 0c1c7a6a83feaf2cf182c52983ffe330ffb50280
patch link: https://lore.kernel.org/r/20251118-only-one-vmalloc-v1-1-29f8eacb4605%40ixit.cz
patch subject: [PATCH] mm/vmalloc: warn only once when vmalloc detect invalid gfp flags
config: alpha-allnoconfig (https://download.01.org/0day-ci/archive/20251118/202511180838.vEBLp7Hm-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251118/202511180838.vEBLp7Hm-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511180838.vEBLp7Hm-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
In file included from arch/alpha/include/asm/bug.h:23,
from include/linux/bug.h:5,
from include/linux/alloc_tag.h:8,
from include/linux/vmalloc.h:5,
from mm/vmalloc.c:11:
mm/vmalloc.c: In function 'vmalloc_fix_flags':
>> mm/vmalloc.c:3938:19: error: expected ')' before 'invalid_mask'
3938 | invalid_mask, &invalid_mask, flags, &flags);
| ^~~~~~~~~~~~
include/asm-generic/bug.h:105:62: note: in definition of macro '__WARN_printf'
105 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
| ^~~
include/linux/once_lite.h:31:25: note: in expansion of macro 'WARN'
31 | func(__VA_ARGS__); \
| ^~~~
include/asm-generic/bug.h:159:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
159 | DO_ONCE_LITE_IF(condition, WARN, 1, format)
| ^~~~~~~~~~~~~~~
mm/vmalloc.c:3937:9: note: in expansion of macro 'WARN_ONCE'
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~
include/asm-generic/bug.h:105:34: note: to match this '('
105 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
| ^
include/asm-generic/bug.h:141:17: note: in expansion of macro '__WARN_printf'
141 | __WARN_printf(TAINT_WARN, format); \
| ^~~~~~~~~~~~~
include/linux/once_lite.h:31:25: note: in expansion of macro 'WARN'
31 | func(__VA_ARGS__); \
| ^~~~
include/asm-generic/bug.h:159:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
159 | DO_ONCE_LITE_IF(condition, WARN, 1, format)
| ^~~~~~~~~~~~~~~
mm/vmalloc.c:3937:9: note: in expansion of macro 'WARN_ONCE'
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~
>> mm/vmalloc.c:3937:22: warning: format '%x' expects a matching 'unsigned int' argument [-Wformat=]
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:105:62: note: in definition of macro '__WARN_printf'
105 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
| ^~~
include/linux/once_lite.h:31:25: note: in expansion of macro 'WARN'
31 | func(__VA_ARGS__); \
| ^~~~
include/asm-generic/bug.h:159:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
159 | DO_ONCE_LITE_IF(condition, WARN, 1, format)
| ^~~~~~~~~~~~~~~
mm/vmalloc.c:3937:9: note: in expansion of macro 'WARN_ONCE'
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~
mm/vmalloc.c:3937:41: note: format string is defined here
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ~~^
| |
| unsigned int
>> mm/vmalloc.c:3937:22: warning: format '%p' expects a matching 'void *' argument [-Wformat=]
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:105:62: note: in definition of macro '__WARN_printf'
105 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
| ^~~
include/linux/once_lite.h:31:25: note: in expansion of macro 'WARN'
31 | func(__VA_ARGS__); \
| ^~~~
include/asm-generic/bug.h:159:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
159 | DO_ONCE_LITE_IF(condition, WARN, 1, format)
| ^~~~~~~~~~~~~~~
mm/vmalloc.c:3937:9: note: in expansion of macro 'WARN_ONCE'
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~
mm/vmalloc.c:3937:45: note: format string is defined here
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ~^
| |
| void *
>> mm/vmalloc.c:3937:22: warning: format '%x' expects a matching 'unsigned int' argument [-Wformat=]
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:105:62: note: in definition of macro '__WARN_printf'
105 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
| ^~~
include/linux/once_lite.h:31:25: note: in expansion of macro 'WARN'
31 | func(__VA_ARGS__); \
| ^~~~
include/asm-generic/bug.h:159:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
159 | DO_ONCE_LITE_IF(condition, WARN, 1, format)
| ^~~~~~~~~~~~~~~
mm/vmalloc.c:3937:9: note: in expansion of macro 'WARN_ONCE'
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~
mm/vmalloc.c:3937:71: note: format string is defined here
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ~~^
| |
| unsigned int
>> mm/vmalloc.c:3937:22: warning: format '%p' expects a matching 'void *' argument [-Wformat=]
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:105:62: note: in definition of macro '__WARN_printf'
105 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
| ^~~
include/linux/once_lite.h:31:25: note: in expansion of macro 'WARN'
31 | func(__VA_ARGS__); \
| ^~~~
include/asm-generic/bug.h:159:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
159 | DO_ONCE_LITE_IF(condition, WARN, 1, format)
| ^~~~~~~~~~~~~~~
mm/vmalloc.c:3937:9: note: in expansion of macro 'WARN_ONCE'
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ^~~~~~~~~
mm/vmalloc.c:3937:75: note: format string is defined here
3937 | WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
| ~^
| |
| void *
>> mm/vmalloc.c:3934:15: warning: unused variable 'invalid_mask' [-Wunused-variable]
3934 | gfp_t invalid_mask = flags & ~GFP_VMALLOC_SUPPORTED;
| ^~~~~~~~~~~~
vim +3938 mm/vmalloc.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 3921
7179b225631532 Vishal Moola (Oracle 2025-11-12 3922) /*
7179b225631532 Vishal Moola (Oracle 2025-11-12 3923) * See __vmalloc_node_range() for a clear list of supported vmalloc flags.
7179b225631532 Vishal Moola (Oracle 2025-11-12 3924) * This gfp lists all flags currently passed through vmalloc. Currently,
7179b225631532 Vishal Moola (Oracle 2025-11-12 3925) * __GFP_ZERO is used by BPF and __GFP_NORETRY is used by percpu. Both drm
7179b225631532 Vishal Moola (Oracle 2025-11-12 3926) * and BPF also use GFP_USER, which is GFP_KERNEL | __GFP_HARDWALL.
7179b225631532 Vishal Moola (Oracle 2025-11-12 3927) */
7179b225631532 Vishal Moola (Oracle 2025-11-12 3928) #define GFP_VMALLOC_SUPPORTED (GFP_KERNEL | GFP_ATOMIC | GFP_NOWAIT |\
7179b225631532 Vishal Moola (Oracle 2025-11-12 3929) __GFP_NOFAIL | __GFP_ZERO | __GFP_NORETRY |\
7179b225631532 Vishal Moola (Oracle 2025-11-12 3930) __GFP_HARDWALL)
7179b225631532 Vishal Moola (Oracle 2025-11-12 3931)
7179b225631532 Vishal Moola (Oracle 2025-11-12 3932) static gfp_t vmalloc_fix_flags(gfp_t flags)
7179b225631532 Vishal Moola (Oracle 2025-11-12 3933) {
7179b225631532 Vishal Moola (Oracle 2025-11-12 @3934) gfp_t invalid_mask = flags & ~GFP_VMALLOC_SUPPORTED;
7179b225631532 Vishal Moola (Oracle 2025-11-12 3935)
7179b225631532 Vishal Moola (Oracle 2025-11-12 3936) flags &= GFP_VMALLOC_SUPPORTED;
bf791000a32caf David Heidelberg 2025-11-18 @3937 WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n"
7179b225631532 Vishal Moola (Oracle 2025-11-12 @3938) invalid_mask, &invalid_mask, flags, &flags);
7179b225631532 Vishal Moola (Oracle 2025-11-12 3939) return flags;
7179b225631532 Vishal Moola (Oracle 2025-11-12 3940) }
7179b225631532 Vishal Moola (Oracle 2025-11-12 3941)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Tue, Nov 18, 2025 at 01:05:57AM +0100, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Without WARN_ONCE, the logs get spammed immediately after the boot,
> on devices as OnePlus 6T (Snapdragon 845).
Do you have any snippets of the logs? There'll be a particularly helpful
section that says "Unexpected gfp:"...
> Fixes: 7179b2256315 ("mm/vmalloc: warn on invalid vmalloc gfp flags")
For some context, this patch begins enforcing the gfp flags passed into
vmalloc(). If the logs are getting spammed, that means the device is
calling vmalloc() with some unsupported gfp flag, many many times.
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> I'm not 100% sure this is the right solution, but having WARN_ONCE or
> rate limited warnings here helps a lot on devices as OnePlus 6 (sdm845).
Can you check if it still happens on today's mm-new?
I just sent a new version earlier today that also masks off
__GFP_ACCOUNT, and had an iteration earlier that added
__GFP_HARDWALL.
On 18/11/2025 01:34, Vishal Moola (Oracle) wrote:
> On Tue, Nov 18, 2025 at 01:05:57AM +0100, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> Without WARN_ONCE, the logs get spammed immediately after the boot,
>> on devices as OnePlus 6T (Snapdragon 845).
>
> Do you have any snippets of the logs? There'll be a particularly helpful
> section that says "Unexpected gfp:"...
I didn't save it, thou I'll run the kernel with all logs again tomorrow,
what I remember it was "__GFP_ACCOUNT" in unexpected section.
>
>> Fixes: 7179b2256315 ("mm/vmalloc: warn on invalid vmalloc gfp flags")
>
> For some context, this patch begins enforcing the gfp flags passed into
> vmalloc(). If the logs are getting spammed, that means the device is
> calling vmalloc() with some unsupported gfp flag, many many times.
Yes, it was full dmesg buffer just after the boot and I think ongoing.
>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> ---
>> I'm not 100% sure this is the right solution, but having WARN_ONCE or
>> rate limited warnings here helps a lot on devices as OnePlus 6 (sdm845).
>
> Can you check if it still happens on today's mm-new?
> I just sent a new version earlier today that also masks off
> __GFP_ACCOUNT, and had an iteration earlier that added
> __GFP_HARDWALL.
I can try tomorrow, any chance it'll bubble into next-20251118?
Thank you
David
--
David Heidelberg
On Tue, Nov 18, 2025 at 01:51:23AM +0100, David Heidelberg wrote:
> On 18/11/2025 01:34, Vishal Moola (Oracle) wrote:
> > On Tue, Nov 18, 2025 at 01:05:57AM +0100, David Heidelberg via B4 Relay wrote:
> > > From: David Heidelberg <david@ixit.cz>
> > >
> > > Without WARN_ONCE, the logs get spammed immediately after the boot,
> > > on devices as OnePlus 6T (Snapdragon 845).
> >
> > Do you have any snippets of the logs? There'll be a particularly helpful
> > section that says "Unexpected gfp:"...
>
> I didn't save it, thou I'll run the kernel with all logs again tomorrow,
> what I remember it was "__GFP_ACCOUNT" in unexpected section.
Gotcha. That's particular flag has been added to the whitelist as of
today. Hopefully there are no others.
> >
> > > Fixes: 7179b2256315 ("mm/vmalloc: warn on invalid vmalloc gfp flags")
> >
> > For some context, this patch begins enforcing the gfp flags passed into
> > vmalloc(). If the logs are getting spammed, that means the device is
> > calling vmalloc() with some unsupported gfp flag, many many times.
>
> Yes, it was full dmesg buffer just after the boot and I think ongoing.
>
> >
> > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > ---
> > > I'm not 100% sure this is the right solution, but having WARN_ONCE or
> > > rate limited warnings here helps a lot on devices as OnePlus 6 (sdm845).
> >
> > Can you check if it still happens on today's mm-new?
> > I just sent a new version earlier today that also masks off
> > __GFP_ACCOUNT, and had an iteration earlier that added
> > __GFP_HARDWALL.
>
> I can try tomorrow, any chance it'll bubble into next-20251118?
I'm not sure, Andrew should know?
> Thank you
> David
>
> --
> David Heidelberg
>
© 2016 - 2025 Red Hat, Inc.