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

[Linus Torvalds]

On Sat, 21 Feb 2026 at 01:18, Kees Cook <kees@xxxxxxxxxx> wrote:
>
> Please pull these kmalloc_obj treewide refactor for v7.0-rc1.

So I've pulled this, updated the merge message to explain that clang
issue a bit more, and looked at the resulting diff.

It all looks more readable to me (in addition to having the better
type checking), but when looking at the diff it struck me that I think
this could perhaps be made more readable still... In particular, I
reacted to how almost everything was using GFP_KERNEL.

So I did some stupid stats to check:

    git grep ',[  ]*GFP_[_A-Z]*)' |
        sed 's/.*\(GFP_[_A-Z]*\).*/\1/' |
        sort | uniq -c | sort -n

and makes it clear that of the simple single-GFP values we have,
GFP_KERNEL is up there with almost an order of magnitude more users
than the next entry (GFP_ATOMIC).

Which is obviously not surprising at all, but it was good to just
verify that reaction from looking at the diff.

Now, kmalloc_obj() and friends are not the majority of this pattern at
all, but considering that this is a new convenience macro that does
better type handling, maybe we should strive to also make it more
convenient to use?

IOW, how about doing something like this:

    #define pick_first(a, ...) a
    #define GFP(...) pick_first(__VA_ARGS__ __VA_OPT__(,) GFP_KERNEL)

    #define kmalloc_obj(VAR_OR_TYPE, ...)                      \
        __alloc_objs(kmalloc, GFP(__VA_ARGS__), typeof(VAR_OR_TYPE), 1)

and now you can just do

        a = kmalloc_obj(type);

if you just want the default GFP_KERNEL?

(And yeah, those helper macros need better names that don't conflict
with anything else)

           Linus