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

[Alejandro Colomar <alx+linux-hardening@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

Hi Linus,

> Date: 2026-11-12 08:34:13-0800
> From: Linus Torvalds <torvalds@linuxfoundation.org>
>
> On Thu, 12 Nov 2026 at 02:13, Alejandro Colomar
> <alx+linux-hardening@kernel.org> 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".

I don't agree that the code is worse.  It's _different_, just like Rust
forces one to write different code in order to make certain bugs trivial
to reject.  But I don't think having to write malloc_objs(T, 1) is
objectively worse than malloc_obj(T).

But let's agree to disagree.

> 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.

Yes, that's a third alternative, which Kees and I discussed some months
ago in Prague as a mitigation.

> 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.

Indeed, I don't volunteer for writing this patch.  :)
But yeah, it would also work.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]