[PATCH 0/5] mm: Switch gfp_t to unsigned long

[PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
probably not needed for 32-bit. This offers a way out of the GFP flag
scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
machines, while leaving it 32-bit on 32-bit machines.

For mm-internal code that prints raw GFP flags as hex, this just updates
the format specifier to %lx. Presumably developers have a reason for
wanting to see the whole flags word as a number in the log. For printks
outside of mm/, I assume they are only using %x because the authors
didn't know about %pGg, so they are converted to the latter as prep
patches.

Stuff I've done to try and find issues with this:

- Built x86 allmodconfig and arm64 defconfig. Hopefully the 0-day bot
  will alert me to the important builds I'm missing (I briefly tried to
  build s390 and sparc64 but ran into tooling issues and gave up).

- Ran some selftests on a x86 VM.

- Poked around at stuff that refers to ___GFP_LAST_BIT to see if
  anything looks wrong.

- Ran this Coccinelle script to look for explicit casts to plain int:

---
virtual report

@r@
gfp_t x;
position p;
@@

(
  (unsigned int)x@p
|
  (int)x@p
)

@script:python depends on report@
p << r.p;
@@
msg = "WARNING: Explicit integer cast of gfp_t"
coccilib.report.print_report(p[0], msg)
---

Obviously this series doesn't "do anything" so maybe it doesn't make
sense to merge it unless it goes in alongside __GFP_UNMAPPED, but it
does seem to make sense to review it independently so I'm posting it as
a separate series.

[0] https://lore.kernel.org/all/6206d021-e6c2-4899-b426-cacd71ebd5ef@kernel.org/

To: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.com>
To: David Rientjes <rientjes@google.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
To: Vlastimil Babka <vbabka@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
To: Brendan Jackman <jackmanb@google.com>
To: Johannes Weiner <hannes@cmpxchg.org>
To: Zi Yan <ziy@nvidia.com>
To: Harry Yoo <harry.yoo@oracle.com>
To: Hao Li <hao.li@linux.dev>
To: Christoph Lameter <cl@gentwo.org>
To: Roman Gushchin <roman.gushchin@linux.dev>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org

Signed-off-by: Brendan Jackman <jackmanb@google.com>

---
Brendan Jackman (5):
      drm/managed: Use special gfp_t format specifier
      iwlegacy: 3945-mac: Use special gfp_t format specifier
      mm/kfence: Use special gfp_t format specifier
      net/rds: Use special gfp_t format specifier
      mm: Change gfp_t to unsigned long

 drivers/gpu/drm/drm_managed.c                  | 4 ++--
 drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++--
 include/linux/types.h                          | 2 +-
 lib/test_lockup.c                              | 2 +-
 mm/kfence/kfence_test.c                        | 2 +-
 mm/oom_kill.c                                  | 2 +-
 mm/page_alloc.c                                | 5 ++++-
 mm/page_owner.c                                | 4 ++--
 mm/slab_common.c                               | 2 +-
 mm/slub.c                                      | 2 +-
 mm/vmalloc.c                                   | 2 +-
 net/rds/tcp_recv.c                             | 2 +-
 12 files changed, 18 insertions(+), 15 deletions(-)
---
base-commit: 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
change-id: 20260319-gfp64-7a970a80ba4e

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

[PATCH 1/5] drm/managed: Use special gfp_t format specifier

[Brendan Jackman]

%pGg produces nice readable output and decouples the format string from
the size of gfp_t.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 drivers/gpu/drm/drm_managed.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index 247f468731de0..a9da94319b052 100644
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -232,8 +232,8 @@ void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
 
 	dr = alloc_dr(NULL, size, gfp, dev_to_node(dev->dev));
 	if (!dr) {
-		drm_dbg_drmres(dev, "failed to allocate %zu bytes, %u flags\n",
-			       size, gfp);
+		drm_dbg_drmres(dev, "failed to allocate %zu bytes, %pGg\n",
+			       size, &gfp);
 		return NULL;
 	}
 	dr->node.name = kstrdup_const("kmalloc", gfp);

-- 
2.51.2

[PATCH 2/5] iwlegacy: 3945-mac: Use special gfp_t format specifier

[Brendan Jackman]

%pGg produces nice readable output and decouples the format string from
the size of gfp_t.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index c148654aa9533..ced85eb7522e9 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -1002,9 +1002,9 @@ il3945_rx_allocate(struct il_priv *il, gfp_t priority)
 				D_INFO("Failed to allocate SKB buffer.\n");
 			if (rxq->free_count <= RX_LOW_WATERMARK &&
 			    net_ratelimit())
-				IL_ERR("Failed to allocate SKB buffer with %0x."
+				IL_ERR("Failed to allocate SKB buffer with %pGg."
 				       "Only %u free buffers remaining.\n",
-				       priority, rxq->free_count);
+				       &priority, rxq->free_count);
 			/* We don't reschedule replenish work here -- we will
 			 * call the restock method and if it still needs
 			 * more buffers it will schedule replenish */

-- 
2.51.2

[PATCH 3/5] mm/kfence: Use special gfp_t format specifier

[Brendan Jackman]

%pGg produces nice readable output and decouples the format string from
the size of gfp_t.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 mm/kfence/kfence_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kfence/kfence_test.c b/mm/kfence/kfence_test.c
index 5725a367246d9..10424cd25e5a6 100644
--- a/mm/kfence/kfence_test.c
+++ b/mm/kfence/kfence_test.c
@@ -263,7 +263,7 @@ static void *test_alloc(struct kunit *test, size_t size, gfp_t gfp, enum allocat
 		break;
 	}
 
-	kunit_info(test, "%s: size=%zu, gfp=%x, policy=%s, cache=%i\n", __func__, size, gfp,
+	kunit_info(test, "%s: size=%zu, gfp=%pGg, policy=%s, cache=%i\n", __func__, size, &gfp,
 		   policy_name, !!test_cache);
 
 	/*

-- 
2.51.2

[PATCH 4/5] net/rds: Use special gfp_t format specifier

[Brendan Jackman]

%pGg produces nice readable output and decouples the format string from
the size of gfp_t.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 net/rds/tcp_recv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rds/tcp_recv.c b/net/rds/tcp_recv.c
index 49f96ee0c40f6..ffe843ca219c7 100644
--- a/net/rds/tcp_recv.c
+++ b/net/rds/tcp_recv.c
@@ -275,7 +275,7 @@ static int rds_tcp_read_sock(struct rds_conn_path *cp, gfp_t gfp)
 	desc.count = 1; /* give more than one skb per call */
 
 	tcp_read_sock(sock->sk, &desc, rds_tcp_data_recv);
-	rdsdebug("tcp_read_sock for tc %p gfp 0x%x returned %d\n", tc, gfp,
+	rdsdebug("tcp_read_sock for tc %p gfp %pGg returned %d\n", tc, &gfp,
 		 desc.error);
 
 	if (skb_queue_empty_lockless(&sock->sk->sk_receive_queue) &&

-- 
2.51.2

[PATCH 5/5] mm: Change gfp_t to unsigned long

[Brendan Jackman]

GFP flag bits are starting to get scarce. There are upcoming features
that can tolerate being 64-bit only, which offers a simple way to escape
GFP bit scarcity: just make gfp_t 64 bits on 64 bit systems.

Update mm-internal printk formats to use %lx - external format strings
have already been decoupled from the size of gfp_t. Also
lib/test_lockup.c which uses the arg in a module_param_unsafe()
invocation where gfp_t doesn't work.

Some care needs to be taken here with code that converts between ALLOC_*
flags and GFP flags since the former are still unsigned int. The current
code is fine but just to be safe, add a BUILD_BUG_ON() for each GFP
flag that gets converted this way.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 include/linux/types.h | 2 +-
 lib/test_lockup.c     | 2 +-
 mm/oom_kill.c         | 2 +-
 mm/page_alloc.c       | 5 ++++-
 mm/page_owner.c       | 4 ++--
 mm/slab_common.c      | 2 +-
 mm/slub.c             | 2 +-
 mm/vmalloc.c          | 2 +-
 8 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/include/linux/types.h b/include/linux/types.h
index 7e71d260763c7..a8490c1381f99 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -160,7 +160,7 @@ typedef u64 dma_addr_t;
 typedef u32 dma_addr_t;
 #endif
 
-typedef unsigned int __bitwise gfp_t;
+typedef unsigned long __bitwise gfp_t;
 typedef unsigned int __bitwise slab_flags_t;
 typedef unsigned int __bitwise fmode_t;
 
diff --git a/lib/test_lockup.c b/lib/test_lockup.c
index c3fd87d6c2dd0..7adc03ac0b39d 100644
--- a/lib/test_lockup.c
+++ b/lib/test_lockup.c
@@ -130,7 +130,7 @@ module_param(alloc_pages_order, uint, 0400);
 MODULE_PARM_DESC(alloc_pages_order, "page order to allocate");
 
 static gfp_t alloc_pages_gfp = GFP_KERNEL;
-module_param_unsafe(alloc_pages_gfp, uint, 0400);
+module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
 MODULE_PARM_DESC(alloc_pages_gfp, "allocate pages with this gfp_mask, default GFP_KERNEL");
 
 static bool alloc_pages_atomic;
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 5c6c95c169ee8..272ecce090f75 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -458,7 +458,7 @@ static void dump_oom_victim(struct oom_control *oc, struct task_struct *victim)
 
 static void dump_header(struct oom_control *oc)
 {
-	pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), order=%d, oom_score_adj=%d\n",
+	pr_warn("%s invoked oom-killer: gfp_mask=%#lx(%pGg), order=%d, oom_score_adj=%d\n",
 		current->comm, oc->gfp_mask, &oc->gfp_mask, oc->order,
 			current->signal->oom_score_adj);
 	if (!IS_ENABLED(CONFIG_COMPACTION) && oc->order)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2d4b6f1a554ed..f0b9e8a950ee7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4036,7 +4036,7 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
 	va_start(args, fmt);
 	vaf.fmt = fmt;
 	vaf.va = &args;
-	pr_warn("%s: %pV, mode:%#x(%pGg), nodemask=%*pbl",
+	pr_warn("%s: %pV, mode:%#lx(%pGg), nodemask=%*pbl",
 			current->comm, &vaf, gfp_mask, &gfp_mask,
 			nodemask_pr_args(nodemask));
 	va_end(args);
@@ -4504,6 +4504,9 @@ gfp_to_alloc_flags(gfp_t gfp_mask, unsigned int order)
 	 */
 	BUILD_BUG_ON(__GFP_HIGH != (__force gfp_t) ALLOC_MIN_RESERVE);
 	BUILD_BUG_ON(__GFP_KSWAPD_RECLAIM != (__force gfp_t) ALLOC_KSWAPD);
+	/* Alloc flags are unsigned int, gfp_t may be larger. */
+	BUILD_BUG_ON(___GFP_HIGH_BIT >= BITS_PER_TYPE(typeof(alloc_flags)));
+	BUILD_BUG_ON(___GFP_KSWAPD_RECLAIM_BIT >= BITS_PER_TYPE(typeof(alloc_flags)));
 
 	/*
 	 * The caller may dip into page reserves a bit more if the caller
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 8178e0be557f8..70afbdb945b1e 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -558,7 +558,7 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn,
 		return -ENOMEM;
 
 	ret = scnprintf(kbuf, count,
-			"Page allocated via order %u, mask %#x(%pGg), pid %d, tgid %d (%s), ts %llu ns\n",
+			"Page allocated via order %u, mask %#lx(%pGg), pid %d, tgid %d (%s), ts %llu ns\n",
 			page_owner->order, page_owner->gfp_mask,
 			&page_owner->gfp_mask, page_owner->pid,
 			page_owner->tgid, page_owner->comm,
@@ -630,7 +630,7 @@ void __dump_page_owner(const struct page *page)
 	else
 		pr_alert("page_owner tracks the page as freed\n");
 
-	pr_alert("page last allocated via order %u, migratetype %s, gfp_mask %#x(%pGg), pid %d, tgid %d (%s), ts %llu, free_ts %llu\n",
+	pr_alert("page last allocated via order %u, migratetype %s, gfp_mask %#lx(%pGg), pid %d, tgid %d (%s), ts %llu, free_ts %llu\n",
 		 page_owner->order, migratetype_names[mt], gfp_mask, &gfp_mask,
 		 page_owner->pid, page_owner->tgid, page_owner->comm,
 		 page_owner->ts_nsec, page_owner->free_ts_nsec);
diff --git a/mm/slab_common.c b/mm/slab_common.c
index d5a70a831a2a5..548e0d0f9aab3 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1028,7 +1028,7 @@ gfp_t kmalloc_fix_flags(gfp_t flags)
 	gfp_t invalid_mask = flags & GFP_SLAB_BUG_MASK;
 
 	flags &= ~GFP_SLAB_BUG_MASK;
-	pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
+	pr_warn("Unexpected gfp: %#lx (%pGg). Fixing up to gfp: %#lx (%pGg). Fix your code!\n",
 			invalid_mask, &invalid_mask, flags, &flags);
 	dump_stack();
 
diff --git a/mm/slub.c b/mm/slub.c
index 2b2d33cc735cb..083f4e9de3ecb 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4235,7 +4235,7 @@ slab_out_of_memory(struct kmem_cache *s, gfp_t gfpflags, int nid)
 	if ((gfpflags & __GFP_NOWARN) || !__ratelimit(&slub_oom_rs))
 		return;
 
-	pr_warn("SLUB: Unable to allocate memory on CPU %u (of node %d) on node %d, gfp=%#x(%pGg)\n",
+	pr_warn("SLUB: Unable to allocate memory on CPU %u (of node %d) on node %d, gfp=%#lx(%pGg)\n",
 		cpu, cpu_to_node(cpu), nid, gfpflags, &gfpflags);
 	pr_warn("  cache: %s, object size: %u, buffer size: %u, default order: %u, min order: %u\n",
 		s->name, s->object_size, s->size, oo_order(s->oo),
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 61caa55a44027..e353e281fa95d 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3949,7 +3949,7 @@ static gfp_t vmalloc_fix_flags(gfp_t flags)
 	gfp_t invalid_mask = flags & ~GFP_VMALLOC_SUPPORTED;
 
 	flags &= GFP_VMALLOC_SUPPORTED;
-	WARN_ONCE(1, "Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
+	WARN_ONCE(1, "Unexpected gfp: %#lx (%pGg). Fixing up to gfp: %#lx (%pGg). Fix your code!\n",
 		  invalid_mask, &invalid_mask, flags, &flags);
 	return flags;
 }

-- 
2.51.2

Re: [PATCH 5/5] mm: Change gfp_t to unsigned long

[kernel test robot]

Hi Brendan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb]

url:    https://github.com/intel-lab-lkp/linux/commits/Brendan-Jackman/drm-managed-Use-special-gfp_t-format-specifier/20260322-145930
base:   8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
patch link:    https://lore.kernel.org/r/20260319-gfp64-v1-5-2c73b8d42b7f%40google.com
patch subject: [PATCH 5/5] mm: Change gfp_t to unsigned long
config: x86_64-rhel-9.4-kunit (https://download.01.org/0day-ci/archive/20260322/202603221419.9kAfrwc5-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260322/202603221419.9kAfrwc5-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/202603221419.9kAfrwc5-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/module.h:23,
                    from lib/test_lockup.c:8:
>> lib/test_lockup.c:133:47: error: expected ';' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:175:23: note: in definition of macro 'module_param_named_unsafe'
     175 |         param_check_##type(name, &(value));                             \
         |                       ^~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:175:32: error: expected ')' before ',' token
     175 |         param_check_##type(name, &(value));                             \
         |                                ^
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:176:39: error: 'param_ops_unsigned' undeclared here (not in a function); did you mean 'param_ops_uint'?
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |                                       ^~~~~~~~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:47: error: expected '}' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:305:11: note: to match this '{'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |           ^
   include/linux/moduleparam.h:192:9: note: in expansion of macro '__module_param_call'
     192 |         __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1,    \
         |         ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
--
   In file included from include/linux/module.h:23,
                    from test_lockup.c:8:
   test_lockup.c:133:47: error: expected ';' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:175:23: note: in definition of macro 'module_param_named_unsafe'
     175 |         param_check_##type(name, &(value));                             \
         |                       ^~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:175:32: error: expected ')' before ',' token
     175 |         param_check_##type(name, &(value));                             \
         |                                ^
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:176:39: error: 'param_ops_unsigned' undeclared here (not in a function); did you mean 'param_ops_uint'?
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |                                       ^~~~~~~~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:47: error: expected '}' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:305:11: note: to match this '{'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |           ^
   include/linux/moduleparam.h:192:9: note: in expansion of macro '__module_param_call'
     192 |         __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1,    \
         |         ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~


vim +133 lib/test_lockup.c

   131	
   132	static gfp_t alloc_pages_gfp = GFP_KERNEL;
 > 133	module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
   134	MODULE_PARM_DESC(alloc_pages_gfp, "allocate pages with this gfp_mask, default GFP_KERNEL");
   135	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 5/5] mm: Change gfp_t to unsigned long

[kernel test robot]

Hi Brendan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb]

url:    https://github.com/intel-lab-lkp/linux/commits/Brendan-Jackman/drm-managed-Use-special-gfp_t-format-specifier/20260322-145930
base:   8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
patch link:    https://lore.kernel.org/r/20260319-gfp64-v1-5-2c73b8d42b7f%40google.com
patch subject: [PATCH 5/5] mm: Change gfp_t to unsigned long
config: m68k-defconfig (https://download.01.org/0day-ci/archive/20260322/202603222339.TqgmWGnk-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260322/202603222339.TqgmWGnk-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/202603222339.TqgmWGnk-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/module.h:23,
                    from lib/test_lockup.c:8:
>> lib/test_lockup.c:133:47: error: expected ';' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:175:23: note: in definition of macro 'module_param_named_unsafe'
     175 |         param_check_##type(name, &(value));                             \
         |                       ^~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:175:32: error: expected ')' before ',' token
     175 |         param_check_##type(name, &(value));                             \
         |                                ^
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:176:39: error: 'param_ops_unsigned' undeclared here (not in a function); did you mean 'param_ops_uint'?
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |                                       ^~~~~~~~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:47: error: expected '}' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:305:11: note: to match this '{'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |           ^
   include/linux/moduleparam.h:192:9: note: in expansion of macro '__module_param_call'
     192 |         __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1,    \
         |         ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   lib/test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
--
   In file included from include/linux/module.h:23,
                    from test_lockup.c:8:
   test_lockup.c:133:47: error: expected ';' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:175:23: note: in definition of macro 'module_param_named_unsafe'
     175 |         param_check_##type(name, &(value));                             \
         |                       ^~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:175:32: error: expected ')' before ',' token
     175 |         param_check_##type(name, &(value));                             \
         |                                ^
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
>> include/linux/moduleparam.h:176:39: error: 'param_ops_unsigned' undeclared here (not in a function); did you mean 'param_ops_uint'?
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |                                       ^~~~~~~~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:47: error: expected '}' before 'long'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         |                                               ^~~~
   include/linux/moduleparam.h:305:46: note: in definition of macro '__module_param_call'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |                                              ^~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:305:11: note: to match this '{'
     305 |         = { __param_str_##name, THIS_MODULE, ops,                       \
         |           ^
   include/linux/moduleparam.h:192:9: note: in expansion of macro '__module_param_call'
     192 |         __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1,    \
         |         ^~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:176:9: note: in expansion of macro 'module_param_cb_unsafe'
     176 |         module_param_cb_unsafe(name, &param_ops_##type, &value, perm);  \
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/moduleparam.h:149:9: note: in expansion of macro 'module_param_named_unsafe'
     149 |         module_param_named_unsafe(name, name, type, perm)
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~
   test_lockup.c:133:1: note: in expansion of macro 'module_param_unsafe'
     133 | module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
         | ^~~~~~~~~~~~~~~~~~~


vim +133 lib/test_lockup.c

     6	
     7	#include <linux/kernel.h>
   > 8	#include <linux/module.h>
     9	#include <linux/delay.h>
    10	#include <linux/sched.h>
    11	#include <linux/sched/signal.h>
    12	#include <linux/sched/clock.h>
    13	#include <linux/cpu.h>
    14	#include <linux/nmi.h>
    15	#include <linux/mm.h>
    16	#include <linux/uaccess.h>
    17	#include <linux/file.h>
    18	
    19	static unsigned int time_secs;
    20	module_param(time_secs, uint, 0600);
    21	MODULE_PARM_DESC(time_secs, "lockup time in seconds, default 0");
    22	
    23	static unsigned int time_nsecs;
    24	module_param(time_nsecs, uint, 0600);
    25	MODULE_PARM_DESC(time_nsecs, "nanoseconds part of lockup time, default 0");
    26	
    27	static unsigned int cooldown_secs;
    28	module_param(cooldown_secs, uint, 0600);
    29	MODULE_PARM_DESC(cooldown_secs, "cooldown time between iterations in seconds, default 0");
    30	
    31	static unsigned int cooldown_nsecs;
    32	module_param(cooldown_nsecs, uint, 0600);
    33	MODULE_PARM_DESC(cooldown_nsecs, "nanoseconds part of cooldown, default 0");
    34	
    35	static unsigned int iterations = 1;
    36	module_param(iterations, uint, 0600);
    37	MODULE_PARM_DESC(iterations, "lockup iterations, default 1");
    38	
    39	static bool all_cpus;
    40	module_param(all_cpus, bool, 0400);
    41	MODULE_PARM_DESC(all_cpus, "trigger lockup at all cpus at once");
    42	
    43	static int wait_state;
    44	static char *state = "R";
    45	module_param(state, charp, 0400);
    46	MODULE_PARM_DESC(state, "wait in 'R' running (default), 'D' uninterruptible, 'K' killable, 'S' interruptible state");
    47	
    48	static bool use_hrtimer;
    49	module_param(use_hrtimer, bool, 0400);
    50	MODULE_PARM_DESC(use_hrtimer, "use high-resolution timer for sleeping");
    51	
    52	static bool iowait;
    53	module_param(iowait, bool, 0400);
    54	MODULE_PARM_DESC(iowait, "account sleep time as iowait");
    55	
    56	static bool lock_read;
    57	module_param(lock_read, bool, 0400);
    58	MODULE_PARM_DESC(lock_read, "lock read-write locks for read");
    59	
    60	static bool lock_single;
    61	module_param(lock_single, bool, 0400);
    62	MODULE_PARM_DESC(lock_single, "acquire locks only at one cpu");
    63	
    64	static bool reacquire_locks;
    65	module_param(reacquire_locks, bool, 0400);
    66	MODULE_PARM_DESC(reacquire_locks, "release and reacquire locks/irq/preempt between iterations");
    67	
    68	static bool touch_softlockup;
    69	module_param(touch_softlockup, bool, 0600);
    70	MODULE_PARM_DESC(touch_softlockup, "touch soft-lockup watchdog between iterations");
    71	
    72	static bool touch_hardlockup;
    73	module_param(touch_hardlockup, bool, 0600);
    74	MODULE_PARM_DESC(touch_hardlockup, "touch hard-lockup watchdog between iterations");
    75	
    76	static bool call_cond_resched;
    77	module_param(call_cond_resched, bool, 0600);
    78	MODULE_PARM_DESC(call_cond_resched, "call cond_resched() between iterations");
    79	
    80	static bool measure_lock_wait;
    81	module_param(measure_lock_wait, bool, 0400);
    82	MODULE_PARM_DESC(measure_lock_wait, "measure lock wait time");
    83	
    84	static unsigned long lock_wait_threshold = ULONG_MAX;
    85	module_param(lock_wait_threshold, ulong, 0400);
    86	MODULE_PARM_DESC(lock_wait_threshold, "print lock wait time longer than this in nanoseconds, default off");
    87	
    88	static bool test_disable_irq;
    89	module_param_named(disable_irq, test_disable_irq, bool, 0400);
    90	MODULE_PARM_DESC(disable_irq, "disable interrupts: generate hard-lockups");
    91	
    92	static bool disable_softirq;
    93	module_param(disable_softirq, bool, 0400);
    94	MODULE_PARM_DESC(disable_softirq, "disable bottom-half irq handlers");
    95	
    96	static bool disable_preempt;
    97	module_param(disable_preempt, bool, 0400);
    98	MODULE_PARM_DESC(disable_preempt, "disable preemption: generate soft-lockups");
    99	
   100	static bool lock_rcu;
   101	module_param(lock_rcu, bool, 0400);
   102	MODULE_PARM_DESC(lock_rcu, "grab rcu_read_lock: generate rcu stalls");
   103	
   104	static bool lock_mmap_sem;
   105	module_param(lock_mmap_sem, bool, 0400);
   106	MODULE_PARM_DESC(lock_mmap_sem, "lock mm->mmap_lock: block procfs interfaces");
   107	
   108	static unsigned long lock_rwsem_ptr;
   109	module_param_unsafe(lock_rwsem_ptr, ulong, 0400);
   110	MODULE_PARM_DESC(lock_rwsem_ptr, "lock rw_semaphore at address");
   111	
   112	static unsigned long lock_mutex_ptr;
   113	module_param_unsafe(lock_mutex_ptr, ulong, 0400);
   114	MODULE_PARM_DESC(lock_mutex_ptr, "lock mutex at address");
   115	
   116	static unsigned long lock_spinlock_ptr;
   117	module_param_unsafe(lock_spinlock_ptr, ulong, 0400);
   118	MODULE_PARM_DESC(lock_spinlock_ptr, "lock spinlock at address");
   119	
   120	static unsigned long lock_rwlock_ptr;
   121	module_param_unsafe(lock_rwlock_ptr, ulong, 0400);
   122	MODULE_PARM_DESC(lock_rwlock_ptr, "lock rwlock at address");
   123	
   124	static unsigned int alloc_pages_nr;
   125	module_param_unsafe(alloc_pages_nr, uint, 0600);
   126	MODULE_PARM_DESC(alloc_pages_nr, "allocate and free pages under locks");
   127	
   128	static unsigned int alloc_pages_order;
   129	module_param(alloc_pages_order, uint, 0400);
   130	MODULE_PARM_DESC(alloc_pages_order, "page order to allocate");
   131	
   132	static gfp_t alloc_pages_gfp = GFP_KERNEL;
 > 133	module_param_unsafe(alloc_pages_gfp, unsigned long, 0400);
   134	MODULE_PARM_DESC(alloc_pages_gfp, "allocate pages with this gfp_mask, default GFP_KERNEL");
   135	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 5/5] mm: Change gfp_t to unsigned long

[kernel test robot]

Hi Brendan,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb]

url:    https://github.com/intel-lab-lkp/linux/commits/Brendan-Jackman/drm-managed-Use-special-gfp_t-format-specifier/20260322-145930
base:   8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
patch link:    https://lore.kernel.org/r/20260319-gfp64-v1-5-2c73b8d42b7f%40google.com
patch subject: [PATCH 5/5] mm: Change gfp_t to unsigned long
config: arm-randconfig-r131-20260322 (https://download.01.org/0day-ci/archive/20260323/202603230210.EgOkfYR4-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260323/202603230210.EgOkfYR4-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/202603230210.EgOkfYR4-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:31,
                    from arch/arm/include/asm/bug.h:60,
                    from include/linux/bug.h:5,
                    from include/linux/instrumented.h:10,
                    from include/linux/atomic/atomic-instrumented.h:17,
                    from include/linux/atomic.h:82,
                    from include/asm-generic/bitops/lock.h:5,
                    from arch/arm/include/asm/bitops.h:245,
                    from include/linux/bitops.h:67,
                    from include/linux/kernel.h:23,
                    from include/linux/clk.h:13,
                    from drivers/usb/gadget/udc/atmel_usba_udc.c:7:
   drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_alloc_request':
>> include/linux/kern_levels.h:5:25: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'gfp_t' {aka 'long unsigned int'} [-Wformat=]
       5 | #define KERN_SOH        "\001"          /* ASCII Start Of Header */
         |                         ^~~~~~
   include/linux/printk.h:134:25: note: in definition of macro 'no_printk'
     134 |                 _printk(fmt, ##__VA_ARGS__);            \
         |                         ^~~
   include/linux/kern_levels.h:15:25: note: in expansion of macro 'KERN_SOH'
      15 | #define KERN_DEBUG      KERN_SOH "7"    /* debug-level messages */
         |                         ^~~~~~~~
   include/linux/printk.h:641:19: note: in expansion of macro 'KERN_DEBUG'
     641 |         no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
         |                   ^~~~~~~~~~
   drivers/usb/gadget/udc/atmel_usba_udc.h:233:25: note: in expansion of macro 'pr_debug'
     233 |                         pr_debug("udc: " fmt, ## __VA_ARGS__);  \
         |                         ^~~~~~~~
   drivers/usb/gadget/udc/atmel_usba_udc.c:703:9: note: in expansion of macro 'DBG'
     703 |         DBG(DBG_GADGET, "ep_alloc_request: %p, 0x%x\n", _ep, gfp_flags);
         |         ^~~
--
   In file included from include/asm-generic/bug.h:31,
                    from arch/arm/include/asm/bug.h:60,
                    from include/linux/bug.h:5,
                    from include/linux/instrumented.h:10,
                    from include/linux/atomic/atomic-instrumented.h:17,
                    from include/linux/atomic.h:82,
                    from include/asm-generic/bitops/lock.h:5,
                    from arch/arm/include/asm/bitops.h:245,
                    from include/linux/bitops.h:67,
                    from include/linux/kernel.h:23,
                    from include/linux/clk.h:13,
                    from atmel_usba_udc.c:7:
   atmel_usba_udc.c: In function 'usba_ep_alloc_request':
>> include/linux/kern_levels.h:5:25: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'gfp_t' {aka 'long unsigned int'} [-Wformat=]
       5 | #define KERN_SOH        "\001"          /* ASCII Start Of Header */
         |                         ^~~~~~
   include/linux/printk.h:134:25: note: in definition of macro 'no_printk'
     134 |                 _printk(fmt, ##__VA_ARGS__);            \
         |                         ^~~
   include/linux/kern_levels.h:15:25: note: in expansion of macro 'KERN_SOH'
      15 | #define KERN_DEBUG      KERN_SOH "7"    /* debug-level messages */
         |                         ^~~~~~~~
   include/linux/printk.h:641:19: note: in expansion of macro 'KERN_DEBUG'
     641 |         no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
         |                   ^~~~~~~~~~
   atmel_usba_udc.h:233:25: note: in expansion of macro 'pr_debug'
     233 |                         pr_debug("udc: " fmt, ## __VA_ARGS__);  \
         |                         ^~~~~~~~
   atmel_usba_udc.c:703:9: note: in expansion of macro 'DBG'
     703 |         DBG(DBG_GADGET, "ep_alloc_request: %p, 0x%x\n", _ep, gfp_flags);
         |         ^~~


vim +5 include/linux/kern_levels.h

314ba3520e513a Joe Perches 2012-07-30  4  
04d2c8c83d0e3a Joe Perches 2012-07-30 @5  #define KERN_SOH	"\001"		/* ASCII Start Of Header */
04d2c8c83d0e3a Joe Perches 2012-07-30  6  #define KERN_SOH_ASCII	'\001'
04d2c8c83d0e3a Joe Perches 2012-07-30  7  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Matthew Wilcox]

On Thu, Mar 19, 2026 at 04:03:23PM +0000, Brendan Jackman wrote:
> As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
> probably not needed for 32-bit. This offers a way out of the GFP flag
> scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
> machines, while leaving it 32-bit on 32-bit machines.

Ugh.  This grows struct xarray:

struct xarray {
        spinlock_t      xa_lock;
/* private: The rest of the data structure is not to be used directly. */
        gfp_t           xa_flags;
        void __rcu *    xa_head;
};

which grows a lot of key data structures.

It would probably have been good for you to have run pahole before/after
this change and diff the results.

Now, you're probably saying "But this makes no damn sense, why on earth
is xa_flags of type gfp_t?"  And the short answer is "because the radix
tree has a ridiculous API".  But you'll learn all about it with your
new patch in this series which converts xa_flags from being gfp_t to a
plain unsigned int ;-)

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

On Thu Mar 19, 2026 at 4:56 PM UTC, Matthew Wilcox wrote:
> On Thu, Mar 19, 2026 at 04:03:23PM +0000, Brendan Jackman wrote:
>> As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
>> probably not needed for 32-bit. This offers a way out of the GFP flag
>> scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
>> machines, while leaving it 32-bit on 32-bit machines.
>
> Ugh.  This grows struct xarray:
>
> struct xarray {
>         spinlock_t      xa_lock;
> /* private: The rest of the data structure is not to be used directly. */
>         gfp_t           xa_flags;
>         void __rcu *    xa_head;
> };
>
> which grows a lot of key data structures.
>
> It would probably have been good for you to have run pahole before/after
> this change and diff the results.

I will paste the diff at the bottom. I _think_ all the problematic
expansions are downstream of struct xarray, but it's quite likely my
sense for problematic struct expansions is weak.

> Now, you're probably saying "But this makes no damn sense, why on earth
> is xa_flags of type gfp_t?"  And the short answer is "because the radix
> tree has a ridiculous API".  But you'll learn all about it with your
> new patch in this series which converts xa_flags from being gfp_t to a
> plain unsigned int ;-)

Hm... so Can We Just™ turn:

#define radix_tree_root		xarray

... into ... 

struct radix_tree_root {
	struct xarray xarray;
	gfp_t gfp;
};

...? Or do we actually need to find a way to keep the radix_tree_root
from growing too? If so, given that (IIUC?) the radix-tree API is soft
deprecated, I guess we can be pretty simple-minded about it and just
define a fixed set of the GFP flag values people use for this:

enum radix_tree_gfp {
	RADIX_TREE_GFP_KERNEL,
	...
	RADIX_TREE_GFP_KERNEL_NOWARN,
};

const gfp_t radix_tree_gfps[] = {
	[RADIX_TREE_GFP_KERNEL] = GFP_KERNEL,
	...
	[RADIX_TREE_GFP_KERNEL_NOWARN] = GFP_KERNEL | __GFP_NOWARN,
};

Would that make sense?

---

  struct acpi_device_bus_id |   +8
  struct address_space  |  +16
  struct amd_iommu_viommu        |  +16
  struct auxiliary_device   |   +8
  struct bdev_inode     |  +16
  struct blkcg          |   +8
  struct cgroup_subsys  |   +8
  struct chain_allocator |   +8
  struct compact_control |   +8
  struct debugfs_inode_info |  +16
  struct dma_device        |   +8
  struct dmar_domain    |   +8
  struct drm_conn_prop_enum_list |   +8
  struct drm_device      |  +32
  struct drm_file        |  +16
  struct drm_i915_file_private     |  +24
  struct drm_i915_gem_object       |  +24
  struct drm_i915_private          |  +40
  struct drm_master      |  +24
  struct drm_mode_config |  +24
  struct dw_dma         |   +8
  struct ethtool_netdev_state |   +8
  struct ext4_inode_info |  +16
  struct fsnotify_group             |   +8
  struct gendisk        |   +8
  struct hsu_dma        |   +8
  struct hugetlbfs_inode_info |  +16
  struct i915_gem_context          |   +8
  struct i915_gem_object_page_iter |   +8
  struct i915_perf                 |   +8
  struct ida               |   +8
  struct idr            |   +8
  struct ieee80211_if_nan     |   +8
  struct ieee80211_local      |   +8
  struct inet_connection_sock |  +16
  struct inet_sock            |  +16
  struct inode          |  +16
  struct inotify_group_private_data |   +8
  struct __intel_generic_device |  +32
  struct intel_gt                  |  +24
  struct intel_guc                 |  +24
  struct intel_iommu    |   +8
  struct intel_uc                  |  +24
  struct iommufd_viommu          |   +8
  struct iommu_group           |   +8
  struct ipc_ids        |   +8
  struct irq_domain           |   +8
  struct iso_inode_info |  +16
  struct kernfs_root    |   +8
  struct kmem_cache     |   +8
  struct kvm                  |  +32
  struct kvm_arch             |  +24
  struct kvm_mmu_memory_cache |   +8
  struct kvm_vcpu             |  +40
  struct kvm_vcpu_arch        |  +40
  struct loop_device             |   +8
  struct mei_aux_device            |   +8
  struct migration_target_control                               |   +8
  struct mqueue_inode_info |  +16
  struct msdos_inode_info |  +16
  struct msi_dev_domain        |   +8
  struct msi_device_data       |   +8
  struct net_devmem_dmabuf_binding |   +8
  struct netfs_inode    |  +16
  struct netlink_sock           |  +16
  struct nfs_inode         |  +16
  struct nfs_net        |   +8
  struct objpool_head |   +8
  struct oom_control     |   +8
  struct p9_client      |  +16
  struct partial_context             |   +8
  struct phy_link_topology    |   +8
  struct proc_inode     |  +16
  struct protection_domain       |   +8
  struct pts_fs_info     |   +8
  struct raw6_sock      |  +64
  struct regmap               |   +8
  struct rethook      |   +8
  struct rpc_inode      |  +16
  struct sctp_sock            |  +16
  struct serial_ctrl_device |   +8
  struct shmem_inode_info |  +16
  struct shrink_control |   +8
  struct snd_card       |  +16
  struct sock           |  +16
  struct swnode         |   +8
  struct tcf_block      |   +8
  struct tcf_idrinfo          |   +8
  struct tcf_net        |   +8
  struct tg3_dev_id           |   +4
  struct thermal_zone_device |   +8
  struct trace_event_raw_dma_alloc_class |   +8
  struct trace_event_raw_dma_alloc_sgt   |   +8
  struct tracefs_inode  |  +16
  struct ttm_bo_swapout_walk |   +8
  struct v9fs_inode     |  +16
  struct virtio_gpu_device |  +16
  struct virtio_pci_admin_vq                    |   +8
  struct virtio_pci_device                      |   +8
  struct vmap_block_queue    |   +8
  struct worker_pool       |   +8
  struct xarray         |   +8
  struct xhci_stream_info |   +8

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Matthew Wilcox]

On Thu, Mar 19, 2026 at 06:40:59PM +0000, Brendan Jackman wrote:
> I will paste the diff at the bottom. I _think_ all the problematic
> expansions are downstream of struct xarray, but it's quite likely my
> sense for problematic struct expansions is weak.

Urgh, no, it's not all xarray.  There's one in address_space which we're
trying to shrink, not grow.  There's one in struct sock too.

I don't think this idea is worth it.  There are other projects of greater
or lesser churniess which will give us some flags back.  For example,
we could finish the GFP_NOFS and GFP_NOIO removal.  We could finish the
radix_tree -> XArray removal and get back three bits.  That's five bits
without even starting new projects, just finishing old ones.

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

On Thu Mar 19, 2026 at 9:39 PM UTC, Matthew Wilcox wrote:
> On Thu, Mar 19, 2026 at 06:40:59PM +0000, Brendan Jackman wrote:
>> I will paste the diff at the bottom. I _think_ all the problematic
>> expansions are downstream of struct xarray, but it's quite likely my
>> sense for problematic struct expansions is weak.
>
> Urgh, no, it's not all xarray.  There's one in address_space which we're
> trying to shrink, not grow.  

Oh sorry I just assumed that one was xa_flags.

> There's one in struct sock too.

Huh, I suspect I am embarassing myself with this question, but why are
we sensitive to the size of struct sock? It's currently 784 bytes in my
build. Are the adjacent fields very hot, and we need to look up the GFP
flags from hot paths?

> I don't think this idea is worth it.  There are other projects of greater
> or lesser churniess which will give us some flags back.  For example,
> we could finish the GFP_NOFS and GFP_NOIO removal.  We could finish the
> radix_tree -> XArray removal and get back three bits.  That's five bits
> without even starting new projects, just finishing old ones.

Anyway, this also makes sense. But, Vlastimil, I guess you had an
ulterior motive for this suggestion?

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Vlastimil Babka (SUSE)]

On 3/20/26 10:48, Brendan Jackman wrote:
> On Thu Mar 19, 2026 at 9:39 PM UTC, Matthew Wilcox wrote:
>> On Thu, Mar 19, 2026 at 06:40:59PM +0000, Brendan Jackman wrote:
>>> I will paste the diff at the bottom. I _think_ all the problematic
>>> expansions are downstream of struct xarray, but it's quite likely my
>>> sense for problematic struct expansions is weak.
>>
>> Urgh, no, it's not all xarray.  There's one in address_space which we're
>> trying to shrink, not grow.  
> 
> Oh sorry I just assumed that one was xa_flags.
> 
>> There's one in struct sock too.
> 
> Huh, I suspect I am embarassing myself with this question, but why are
> we sensitive to the size of struct sock? It's currently 784 bytes in my
> build. Are the adjacent fields very hot, and we need to look up the GFP
> flags from hot paths?
> 
>> I don't think this idea is worth it.  There are other projects of greater
>> or lesser churniess which will give us some flags back.  For example,
>> we could finish the GFP_NOFS and GFP_NOIO removal.  We could finish the
>> radix_tree -> XArray removal and get back three bits.  That's five bits
>> without even starting new projects, just finishing old ones.
> 
> Anyway, this also makes sense. But, Vlastimil, I guess you had an
> ulterior motive for this suggestion?

Partially. After seeing various issues with kmalloc_nolock() relying on lack
of __GFP_KSWAPD_RECLAIM to indicate the nolock, it would be great to just
add another gfp flag for it, but with only few left, I didn't dare.

But I'll admit it wasn't well thought idea out wrt consequences. Sorry that
nobody shot it down before you actually tried to implement it.

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

On Fri Mar 20, 2026 at 9:48 AM UTC, Brendan Jackman wrote:
> On Thu Mar 19, 2026 at 9:39 PM UTC, Matthew Wilcox wrote:
>> On Thu, Mar 19, 2026 at 06:40:59PM +0000, Brendan Jackman wrote:
>>> I will paste the diff at the bottom. I _think_ all the problematic
>>> expansions are downstream of struct xarray, but it's quite likely my
>>> sense for problematic struct expansions is weak.
>>
>> Urgh, no, it's not all xarray.  There's one in address_space which we're
>> trying to shrink, not grow.  
>
> Oh sorry I just assumed that one was xa_flags.
>
>> There's one in struct sock too.
>
> Huh, I suspect I am embarassing myself with this question, but why are
> we sensitive to the size of struct sock? It's currently 784 bytes in my
> build. Are the adjacent fields very hot, and we need to look up the GFP
> flags from hot paths?
>
>> I don't think this idea is worth it.  There are other projects of greater
>> or lesser churniess which will give us some flags back.  For example,
>> we could finish the GFP_NOFS and GFP_NOIO removal.  We could finish the
>> radix_tree -> XArray removal and get back three bits.  

Oh, but also couldn't we get those 3 back by expanding struct
radix_tree_root as I suggested a few messages back:

-#define radix_tree_root                xarray
+struct radix_tree_root {
+        struct xarray xarray;
+        gfp_t gfp;
+};

That seems to make sense as a way to avoid the xa_flags overload even if
gfp_t doesn't grow.

(_If_ we can tolerate radix_tree_root expansion, which I have no idea
about. Otherwise, yeah seems like finishing the radix-tree migration is
a good path to more GFP flags).

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Vlastimil Babka (SUSE)]

On 3/19/26 17:03, Brendan Jackman wrote:
> As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
> probably not needed for 32-bit. This offers a way out of the GFP flag
> scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
> machines, while leaving it 32-bit on 32-bit machines.

Thanks for tackling this! But now I'm wondering, if we decide to change it,
would it be worth trying to add some type safety too? To help with cases
like the recent kmalloc_objs() footgun discussed in this comment thread
https://lwn.net/Articles/1063356/

> For mm-internal code that prints raw GFP flags as hex, this just updates
> the format specifier to %lx. Presumably developers have a reason for
> wanting to see the whole flags word as a number in the log. For printks
> outside of mm/, I assume they are only using %x because the authors
> didn't know about %pGg, so they are converted to the latter as prep
> patches.
> 
> Stuff I've done to try and find issues with this:
> 
> - Built x86 allmodconfig and arm64 defconfig. Hopefully the 0-day bot
>   will alert me to the important builds I'm missing (I briefly tried to
>   build s390 and sparc64 but ran into tooling issues and gave up).
> 
> - Ran some selftests on a x86 VM.
> 
> - Poked around at stuff that refers to ___GFP_LAST_BIT to see if
>   anything looks wrong.
> 
> - Ran this Coccinelle script to look for explicit casts to plain int:
> 
> ---
> virtual report
> 
> @r@
> gfp_t x;
> position p;
> @@
> 
> (
>   (unsigned int)x@p
> |
>   (int)x@p
> )
> 
> @script:python depends on report@
> p << r.p;
> @@
> msg = "WARNING: Explicit integer cast of gfp_t"
> coccilib.report.print_report(p[0], msg)
> ---
> 
> Obviously this series doesn't "do anything" so maybe it doesn't make
> sense to merge it unless it goes in alongside __GFP_UNMAPPED, but it
> does seem to make sense to review it independently so I'm posting it as
> a separate series.
> 
> [0] https://lore.kernel.org/all/6206d021-e6c2-4899-b426-cacd71ebd5ef@kernel.org/
> 
> To: Andrew Morton <akpm@linux-foundation.org>
> To: Michal Hocko <mhocko@suse.com>
> To: David Rientjes <rientjes@google.com>
> To: Shakeel Butt <shakeel.butt@linux.dev>
> To: Vlastimil Babka <vbabka@kernel.org>
> To: Suren Baghdasaryan <surenb@google.com>
> To: Brendan Jackman <jackmanb@google.com>
> To: Johannes Weiner <hannes@cmpxchg.org>
> To: Zi Yan <ziy@nvidia.com>
> To: Harry Yoo <harry.yoo@oracle.com>
> To: Hao Li <hao.li@linux.dev>
> To: Christoph Lameter <cl@gentwo.org>
> To: Roman Gushchin <roman.gushchin@linux.dev>
> To: Uladzislau Rezki <urezki@gmail.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mm@kvack.org
> 
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> 
> ---
> Brendan Jackman (5):
>       drm/managed: Use special gfp_t format specifier
>       iwlegacy: 3945-mac: Use special gfp_t format specifier
>       mm/kfence: Use special gfp_t format specifier
>       net/rds: Use special gfp_t format specifier
>       mm: Change gfp_t to unsigned long
> 
>  drivers/gpu/drm/drm_managed.c                  | 4 ++--
>  drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++--
>  include/linux/types.h                          | 2 +-
>  lib/test_lockup.c                              | 2 +-
>  mm/kfence/kfence_test.c                        | 2 +-
>  mm/oom_kill.c                                  | 2 +-
>  mm/page_alloc.c                                | 5 ++++-
>  mm/page_owner.c                                | 4 ++--
>  mm/slab_common.c                               | 2 +-
>  mm/slub.c                                      | 2 +-
>  mm/vmalloc.c                                   | 2 +-
>  net/rds/tcp_recv.c                             | 2 +-
>  12 files changed, 18 insertions(+), 15 deletions(-)
> ---
> base-commit: 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
> change-id: 20260319-gfp64-7a970a80ba4e
> 
> Best regards,

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> wrote:
>
> On 3/19/26 17:03, Brendan Jackman wrote:
> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
> > probably not needed for 32-bit. This offers a way out of the GFP flag
> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
> > machines, while leaving it 32-bit on 32-bit machines.
>
> Thanks for tackling this! But now I'm wondering, if we decide to change it,
> would it be worth trying to add some type safety too? To help with cases
> like the recent kmalloc_objs() footgun discussed in this comment thread
> https://lwn.net/Articles/1063356/

Do you mean something similar to pgprot_t?

I did that in [0] but I'm rather sheepish about it, I only went for it
because I think it's especially needed for the specific "type" due to
the migration path creating a high type-unsafety risk. And that was
totally local to a few files in mm/.

Are there common issues with gfp_t in particular besides the
kmalloc_objs() thing? If so then maybe it could make sense. It's not a
problem I've ever run into myself though.

[0] https://lore.kernel.org/all/20260225-page_alloc-unmapped-v1-8-e8808a03cd66@google.com/

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Vlastimil Babka (SUSE)]

On 3/19/26 18:38, Brendan Jackman wrote:
> On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> wrote:
>>
>> On 3/19/26 17:03, Brendan Jackman wrote:
>> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
>> > probably not needed for 32-bit. This offers a way out of the GFP flag
>> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
>> > machines, while leaving it 32-bit on 32-bit machines.
>>
>> Thanks for tackling this! But now I'm wondering, if we decide to change it,
>> would it be worth trying to add some type safety too? To help with cases
>> like the recent kmalloc_objs() footgun discussed in this comment thread
>> https://lwn.net/Articles/1063356/
> 
> Do you mean something similar to pgprot_t?

Yeah, at least I don't know a better way.

> I did that in [0] but I'm rather sheepish about it, I only went for it

Right.

> because I think it's especially needed for the specific "type" due to
> the migration path creating a high type-unsafety risk. And that was
> totally local to a few files in mm/.
> 
> Are there common issues with gfp_t in particular besides the
> kmalloc_objs() thing? If so then maybe it could make sense. It's not a
> problem I've ever run into myself though.

I think it's a hazard in any case where there are multiple arguments to a
function where one is gfp flags and other some integer, and somebody gets
the order wrong.

But I just verified that at least in the kmalloc_objs() mistake, sparse will
flag it, thanks to the __bitwise annotation. Would be better if compiler
did, but it makes the case for changing gfp_t smaller if it was too
disruptive (it likely would be).

> [0] https://lore.kernel.org/all/20260225-page_alloc-unmapped-v1-8-e8808a03cd66@google.com/

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

On Thu Mar 19, 2026 at 7:58 PM UTC, Vlastimil Babka (SUSE) wrote:
> On 3/19/26 18:38, Brendan Jackman wrote:
>> On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> wrote:
>>>
>>> On 3/19/26 17:03, Brendan Jackman wrote:
>>> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
>>> > probably not needed for 32-bit. This offers a way out of the GFP flag
>>> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
>>> > machines, while leaving it 32-bit on 32-bit machines.
>>>
>>> Thanks for tackling this! But now I'm wondering, if we decide to change it,
>>> would it be worth trying to add some type safety too? To help with cases
>>> like the recent kmalloc_objs() footgun discussed in this comment thread
>>> https://lwn.net/Articles/1063356/
>> 
>> Do you mean something similar to pgprot_t?
>
> Yeah, at least I don't know a better way.
>
>> I did that in [0] but I'm rather sheepish about it, I only went for it
>
> Right.
>
>> because I think it's especially needed for the specific "type" due to
>> the migration path creating a high type-unsafety risk. And that was
>> totally local to a few files in mm/.
>> 
>> Are there common issues with gfp_t in particular besides the
>> kmalloc_objs() thing? If so then maybe it could make sense. It's not a
>> problem I've ever run into myself though.
>
> I think it's a hazard in any case where there are multiple arguments to a
> function where one is gfp flags and other some integer, and somebody gets
> the order wrong.

I think this is a C problem rather than a gfp_t problem though. Better
to try and tackle it with treewide efforts like Sparse and Rust IMO.

(Maybe gfp_t is the most common type of arg flags in the kernel? Could
be an argument to be made there I guess).

> But I just verified that at least in the kmalloc_objs() mistake, sparse will
> flag it, thanks to the __bitwise annotation. Would be better if compiler
> did, but it makes the case for changing gfp_t smaller if it was too
> disruptive (it likely would be).

Yeah I think it would be very disruptive indeed.

A thought I'll forward to Roman - we should try having Sashiko[1] run
Sparse and read the output, if it doesn't already. 

[1] https://lwn.net/Articles/1063292/

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Zi Yan]

On 19 Mar 2026, at 12:03, Brendan Jackman wrote:

> As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
> probably not needed for 32-bit. This offers a way out of the GFP flag
> scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
> machines, while leaving it 32-bit on 32-bit machines.
>
> For mm-internal code that prints raw GFP flags as hex, this just updates
> the format specifier to %lx. Presumably developers have a reason for
> wanting to see the whole flags word as a number in the log. For printks
> outside of mm/, I assume they are only using %x because the authors
> didn't know about %pGg, so they are converted to the latter as prep
> patches.

I think these %lx -> %pGg patches can be merged. They are nice cleanups.
Thank you for doing that.

Feel free to add Reviewed-by: Zi Yan <ziy@nvidia.com> to the first 4 patches.
(I did not put the tag in a newline, so that b4 will not mistakenly
take it for the whole series)

For patch 5, I will wait until you address the feedback from Vlastimil
and Matthew.

>
> Stuff I've done to try and find issues with this:
>
> - Built x86 allmodconfig and arm64 defconfig. Hopefully the 0-day bot
>   will alert me to the important builds I'm missing (I briefly tried to
>   build s390 and sparc64 but ran into tooling issues and gave up).
>
> - Ran some selftests on a x86 VM.
>
> - Poked around at stuff that refers to ___GFP_LAST_BIT to see if
>   anything looks wrong.
>
> - Ran this Coccinelle script to look for explicit casts to plain int:
>
> ---
> virtual report
>
> @r@
> gfp_t x;
> position p;
> @@
>
> (
>   (unsigned int)x@p
> |
>   (int)x@p
> )
>
> @script:python depends on report@
> p << r.p;
> @@
> msg = "WARNING: Explicit integer cast of gfp_t"
> coccilib.report.print_report(p[0], msg)
> ---
>
> Obviously this series doesn't "do anything" so maybe it doesn't make
> sense to merge it unless it goes in alongside __GFP_UNMAPPED, but it
> does seem to make sense to review it independently so I'm posting it as
> a separate series.
>
> [0] https://lore.kernel.org/all/6206d021-e6c2-4899-b426-cacd71ebd5ef@kernel.org/
>
> To: Andrew Morton <akpm@linux-foundation.org>
> To: Michal Hocko <mhocko@suse.com>
> To: David Rientjes <rientjes@google.com>
> To: Shakeel Butt <shakeel.butt@linux.dev>
> To: Vlastimil Babka <vbabka@kernel.org>
> To: Suren Baghdasaryan <surenb@google.com>
> To: Brendan Jackman <jackmanb@google.com>
> To: Johannes Weiner <hannes@cmpxchg.org>
> To: Zi Yan <ziy@nvidia.com>
> To: Harry Yoo <harry.yoo@oracle.com>
> To: Hao Li <hao.li@linux.dev>
> To: Christoph Lameter <cl@gentwo.org>
> To: Roman Gushchin <roman.gushchin@linux.dev>
> To: Uladzislau Rezki <urezki@gmail.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mm@kvack.org
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
>
> ---
> Brendan Jackman (5):
>       drm/managed: Use special gfp_t format specifier
>       iwlegacy: 3945-mac: Use special gfp_t format specifier
>       mm/kfence: Use special gfp_t format specifier
>       net/rds: Use special gfp_t format specifier
>       mm: Change gfp_t to unsigned long
>
>  drivers/gpu/drm/drm_managed.c                  | 4 ++--
>  drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++--
>  include/linux/types.h                          | 2 +-
>  lib/test_lockup.c                              | 2 +-
>  mm/kfence/kfence_test.c                        | 2 +-
>  mm/oom_kill.c                                  | 2 +-
>  mm/page_alloc.c                                | 5 ++++-
>  mm/page_owner.c                                | 4 ++--
>  mm/slab_common.c                               | 2 +-
>  mm/slub.c                                      | 2 +-
>  mm/vmalloc.c                                   | 2 +-
>  net/rds/tcp_recv.c                             | 2 +-
>  12 files changed, 18 insertions(+), 15 deletions(-)
> ---
> base-commit: 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
> change-id: 20260319-gfp64-7a970a80ba4e
>
> Best regards,
> -- 
> Brendan Jackman <jackmanb@google.com>


Best Regards,
Yan, Zi

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

Human summary of Sashiko (AI) review [0]

[PATCH 2/5] iwlegacy: 3945-mac: Use special gfp_t format specifier

  Just identifying pre-existing (and low-stakes) issues in the code. I
  can add a patch to fix them up.

  Andrew, I think it probably makes sense to merge these cleanup patches
  regardless of the gfp_t change, as Zi said. Would you take them
  through mm or would they need to go via the more specific branches?

[PATCH 5/5] mm: Change gfp_t to unsigned long

  - 1 << __GFP_BITS_SHIFT needs to be updated to use 1UL.

  - Need to update userspace tools like perf.

  - Says I can't use unsigned long in module_param_unsafe(), which I
    think is true. I did that to address a build failure, maybe I never
    actually repeated the build?

Other patches got a green tick.

[0] https://sashiko.dev/#/patchset/20260319-gfp64-v1-0-2c73b8d42b7f%40google.com

Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Andrew Morton]

On Fri, 20 Mar 2026 09:37:52 +0000 Brendan Jackman <jackmanb@google.com> wrote:

> Human summary of Sashiko (AI) review [0]
> 
> [PATCH 2/5] iwlegacy: 3945-mac: Use special gfp_t format specifier
> 
>   Just identifying pre-existing (and low-stakes) issues in the code. I
>   can add a patch to fix them up.
> 
>   Andrew, I think it probably makes sense to merge these cleanup patches
>   regardless of the gfp_t change, as Zi said. Would you take them
>   through mm or would they need to go via the more specific branches?

In an ideal world the subsystem trees would take such changes.

In the real world it's more reliable for me to take them all, make sure
the relevant maintainers are cc'ed.  If they ack the patch then great. 
If they merge the patch then I'll drop the mm.git duplicate.  If they
say nothing and it has decent linux-next exposure then ho hum, in it
goes.