linux-kernel - Re: [cocci] [PATCH v5 4/4] coccinelle: Add kmalloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <202512111352.387A339CE@keescook>
Date: Thu, 11 Dec 2025 14:00:02 -0800
From: Kees Cook <kees@...nel.org>
To: Markus Elfring <Markus.Elfring@....de>
Cc: cocci@...ia.fr, linux-hardening@...r.kernel.org, linux-mm@...ck.org,
	Julia Lawall <Julia.Lawall@...ia.fr>,
	Nicolas Palix <nicolas.palix@...g.fr>,
	LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
	llvm@...ts.linux.dev,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Alexander Potapenko <glider@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bill Wendling <morbo@...gle.com>, Christoph Lameter <cl@...ux.com>,
	David Rientjes <rientjes@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Gustavo A. R. Silva" <gustavoars@...nel.org>,
	Harry Yoo <harry.yoo@...cle.com>, Jakub Kicinski <kuba@...nel.org>,
	Jan Hendrik Farr <kernel@...rr.cc>, Jann Horn <jannh@...gle.com>,
	Jonathan Corbet <corbet@....net>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Justin Stitt <justinstitt@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Marco Elver <elver@...gle.com>,
	Matthew Wilcox <willy@...radead.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Pekka Enberg <penberg@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Sasha Levin <sashal@...nel.org>,
	Tony Ambardar <tony.ambardar@...il.com>,
	Vegard Nossum <vegard.nossum@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Yafang Shao <laoar.shao@...il.com>
Subject: Re: [cocci] [PATCH v5 4/4] coccinelle: Add kmalloc_objs conversion
 script

On Mon, Nov 24, 2025 at 01:50:23PM +0100, Markus Elfring wrote:
> > Finds and converts sized kmalloc-family of allocations into the
> > typed kmalloc_obj-family of allocations.
> 
> See also:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.18-rc7#n94

"Describe your changes in imperative mood"

I guess I can try rewording this, but it is describing the behavior of
the script. Normally the imperative language for a patch is about what
the patch accomplishes. In this case, I've added a script and it does a
thing itself.

> …
> > +++ b/scripts/coccinelle/api/kmalloc_objs.cocci
> > @@ -0,0 +1,168 @@
> …
> > +// Comments:
> …
> 
> * Please omit such an empty information line.

Agreed; I removed this in v5.

> 
> * Would a field like “Keywords” become helpful?

I only see a few using this -- what benefit is there to adding it? It
seems redundant to the rest of the file, its opening comment, etc.

> > +virtual patch
> 
> Will additional operation modes become relevant after clarification of implementation details?

I am not interested in other modes; if people want to contribute them,
they are welcome. :)

> 
> 
> …
> > +def alloc_array(name):
> > +	func = "FAILED_RENAME"
> > +	if name == "kmalloc_array":
> > +		func = "kmalloc_objs"
> …
> 
> * I suggest to avoid duplicate variable assignments.
> 
> * How do you think about to collaborate with the Python data structure “dictionary”?

I wanted the stderr warning when there was no match, but to return
"FAILED_RENAME" in such a case. Using a dictionary was basically the
same length as the elif stack. If you have an alternative, I'm happy to
replace it with what you come up with.

> 
> 
> …
> > +type TYPE;
> > +TYPE *P;
> > +TYPE INST;
> > +expression VAR;
> > +expression GFP;
> …
> 
> Such repetition of SmPL key words can eventually be also avoided.

That is true, but I like having them separated -- I find it more
readable that way.

-- 
Kees Cook