linux-kernel - Re: [PATCH] fs: Rename the parameter of mnt_get_write

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250516235739.GV2023217@ZenIV>
Date: Sat, 17 May 2025 00:57:39 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Zizhi Wo <wozizhi@...weicloud.com>
Cc: Jan Kara <jack@...e.cz>, brauner@...nel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	yangerkun@...wei.com
Subject: Re: [PATCH] fs: Rename the parameter of mnt_get_write_access()

On Sat, May 17, 2025 at 07:54:55AM +0800, Zizhi Wo wrote:
> 
> 
> 在 2025/5/16 18:31, Jan Kara 写道:
> > On Fri 16-05-25 11:21:47, Zizhi Wo wrote:
> > > From: Zizhi Wo <wozizhi@...wei.com>
> > > 
> > > Rename the parameter in mnt_get_write_access() from "m" to "mnt" for
> > > consistency between declaration and implementation.
> > > 
> > > Signed-off-by: Zizhi Wo <wozizhi@...wei.com>
> > 
> > I'm sorry but this is just a pointless churn. I agree the declaration and
> > implementation should better be consistent (although in this particular
> > case it isn't too worrying) but it's much easier (and with much lower
> > chance to cause conflicts) to just fixup the declaration.
> > 
> > 								Honza
> 
> Yes, I had considered simply fixing the declaration earlier. However, in
> the include/linux/mount.h file, similar functions like
> "mnt_put_write_access" use "mnt" as the parameter name rather than "m",
> just like "mnt_get_write_access". So I chose to modify the function
> implementation directly, although this resulted in a larger amount of
> changes. So as you can see, for simplicity, I will directly update the
> parameter name in the function declaration in the second version.

FWIW, "mnt for vfsmount, m for mount" is an informal convention in that
area, so I'd say go for it if there had been any change in the function
in question.  Same as with coding style, really...