Re: [GIT PULL] kmalloc_obj treewide refactor for v7.0-rc1

[Kees Cook <kees@kernel.org>]

On Sat, Feb 21, 2026 at 08:52:55PM -0800, Linus Torvalds wrote:
> So I decided to just do this now, because it's going to cause
> unnecessary merge conflict pain if I do it at any other time.

Sounds good; thanks for doing this!

> I'm adding Julia, because for the line-wrapping case I first tried to
> use coccinelle to do it, but spatch failed on me half-way with an
> assertion failure in kernel/trace/trace_events_hist.c, which I
> couldn't figure out.
> 
> My script was probably to blame, but it boiled down to basically just
> 
>   -ALLOC(E, GFP_KERNEL)
>   +ALLOC(E)

You can break up match elements across lines, so you can drop the
", GFP_KERNEL" portion explicitly without needing to capture the rest of
the line, and since it's always the last argument, you can use "..." to
avoid needing to do any syntactic evaluation of the prior arguments. This
seems to catch the remaining:

@gfp@
identifier ALLOC = {kmalloc_obj,kmalloc_objs,kmalloc_flex,
		    kzalloc_obj,kzalloc_objs,kzalloc_flex,
		    kvmalloc_obj,kvmalloc_objs,kvmalloc_flex,
		    kvzalloc_obj,kvzalloc_objs,kvzalloc_flex};
@@

	ALLOC(...
-		, GFP_KERNEL
	)

Which results in:

 415 files changed, 612 insertions(+), 833 deletions(-)

> And yes, I verified the end result by not just building it, but also
> booting it.

I'm sorry again about the glitch. As Eric noted about it not being
in -next, it's a risk of these tree-wide refactors is their lack of
(infeasible) bake time in -next. But maybe there's a way to do it that
I didn't see that doesn't cause giant pain for merging it into -next.

I will (boot!) test the above output, and send a patch in the morning
if you don't beat me to it. :)

-Kees

-- 
Kees Cook