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

[Justin Stitt <justinstitt@google.com>]

Hi,

On Thu, Nov 12, 2026 at 09:23:18AM -0800, Linus Torvalds wrote:
> On Thu, 12 Nov 2026 at 09:09, Kees Cook <kees@kernel.org> wrote:
> >
> > One thing Justin was poking at was adding a "strict" mode to typedef
> 
> Honestly, the sparse setup is superior. It does that 'strict' thing
> (except it calls it 'nocast') _and_ it has 'bitwise' that is a nocast
> that also disallows non-bit type checks (which is *very* useful for
> things like "this is a big-endian value: you can only do bitwise
> checks against other big-endian values).


Cool. I wasn't super familiar with how sparse handled `nocast` and
`bitwise` but your insights led me to look into it deeper. I'll take
these learnings over to clang when I get around to implementing strict
types :)

> 
> So the compiler addition may be worth it, but  even the "poking at" is
> weaker than what sparse already does.

Right but I suppose the benefit is that compiler-enforced things are
caught vastly more often than sparse-enforced things. Plus, like I said
above, maybe I can aim to reach relative feature parity with sparse's
own analysis on this type of stuff.

FYI, there's some prior design with `strong` typedefs [1] in the form of
a wg14 proposal. I've also been keeping a close eye on that stuff as it
develops because it's essentially strict/distinct types with a different
name.

[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3320.htm

Justin