Re: [PATCH 2/2] devres: Provide kmalloc_obj*-style API for devm_kmalloc

[Kees Cook]

On Thu, Nov 12, 2026 at 08:34:13AM -0800, Linus Torvalds wrote:
> On Thu, 12 Nov 2026 at 02:13, Alejandro Colomar
> <alx+linux-hardening@xxxxxxxxxx> wrote:
> >
> > I suggest removing kmalloc_obj() entirely, and using kmalloc_objs()
> > always, with a second argument of 1 when we want a single object.  This
> > would remove the risk of that typo.
> >
> > I also suggest having default arguments without variadic macros.  The
> > way to do that is using empty arguments.  Linus complained that it hurts
> > his eyes, but it really makes these macros much safer.
> 
> No to both. These are both "make the code worse to catch errors that
> the compiler should have been able to catch anyway".
> 
> If you *really* want to catch them, make "gfp_t" be a 'struct'. That
> way even compilers without things like the restricted types that
> sparse has will catch at least that one.
> 
> I did that many many years (argh, decades - I'm old) ago to catch all
> the 'pte_t' etc issues when rewriting the MM layer, and it works very
> well.
> 
> It's going to be somewhat painful, but ti might be worth it. People
> who only use GFP_xyz flags to pass them around wouldn't notice.

One thing Justin was poking at was adding a "strict" mode to typedef
that gets us a new native type that follows all the same rules as its
underlying type, but refuses implicit casting. That way you get stuff
like gfp_t or pid_t that still works sanely but refuses to take values
from non-matching types (i.e. it would catch this case). It's handy for
the Overflow Behavior Type work too (for similar reasons). e.g.:

typedef __distinct unsigned int pid_t;

or something like that. Then you don't need the accessors like we have
for the struct-style wrappers.

-Kees

-- 
Kees Cook