linux-kernel - Re: [PATCH] KEYS: encrypted: Use designated initializers for match_table

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: <d51ffec03676bcd6f5427f81829073f06921d84f.camel@huaweicloud.com>
Date: Thu, 23 Oct 2025 15:35:37 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>, Thorsten Blum
	 <thorsten.blum@...ux.dev>
Cc: Mimi Zohar <zohar@...ux.ibm.com>, David Howells <dhowells@...hat.com>, 
 Jarkko Sakkinen <jarkko@...nel.org>, Paul Moore <paul@...l-moore.com>,
 James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
 linux-integrity@...r.kernel.org, keyrings@...r.kernel.org, 
 linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KEYS: encrypted: Use designated initializers for
 match_table_t structs

On Thu, 2025-10-09 at 09:51 -0400, James Bottomley wrote:
> On Thu, 2025-10-09 at 15:30 +0200, Thorsten Blum wrote:
> > On 9. Oct 2025, at 14:44, James Bottomley wrote:
> > > On Thu, 2025-10-09 at 13:58 +0200, Thorsten Blum wrote:
> > > > Use designated initializers for 'key_format_tokens' and
> > > > 'key_tokens' to allow struct fields to be reordered more easily
> > > 
> > > How does it improve that?  The key,value pairs are surrounded by
> > > braces so we just cut and paste the lot anyway.
> > 
> > Using designated initializers (especially for global structs) allows
> > the fields of struct match_token from linux/parser.h to be reordered
> > or extended more easily, improving overall maintainability.
> 
> Why would we ever want to reorder them?  The reason the ordering is
> {token, parser} string is because that's the nicest order to read them
> in.

I also join James regarding this. I find it fine as it is.

Consider also that there might be patches depending on this change that
cannot be automatically ported to stable kernels. Then, extra work is
required to find which dependencies are needed and backport them as
well.

Thanks

Roberto

> > > > and to improve readability.
> > > 
> > > I don't think I agree with this when looking through the code,
> > > especially because this is the way it's done for *every* option in
> > > the entire key subsystem.  So firstly I really don't think it's
> > > helpful for only encrypted keys to be different from everything
> > > else and secondly when I read the code (as I often do to figure out
> > > what the options mean), the additional .token and .pattern just get
> > > in the way of what I'm looking for.
> > 
> > I just stumbled upon this and didn't check any other files.
> 
> jejb@...grow:~/git/linux> git grep 'match_table_t'|wc -l
> 49
> 
> I'll leave it as an exercise to you to figure out how many use the
> style you're proposing.
> 
> There's definite advantage in uniformity and even if I accepted the
> readability argument, which I don't, it's too small a reason to churn
> nearly 50 files one at a time.
> 
> Regards,
> 
> James
>