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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAOQ4uxiT=v9JKS39ii-em0XFNkWyskW_Ed3kxS5PE5Q2Rs+NMQ@mail.gmail.com>
Date: Thu, 22 May 2025 09:41:51 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Zizhi Wo <wozizhi@...weicloud.com>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz, 
	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 Thu, May 22, 2025 at 3:02 AM Zizhi Wo <wozizhi@...weicloud.com> wrote:
>
> Hello!
>
> There are currently two possible approaches to this patch.
> The first is to directly change the declaration, which would be
> straightforward and involve minimal modifications.
>
> However, per Al Viro's suggestion — that "mnt for vfsmount, m for mount"
> is an informal convention. This is in line with what the current
> patch does, although I understand Jan Kara might feel that the scope of
> the changes is a bit large.
>
> I would appreciate any suggestions or guidance on how to proceed. So
> friendly ping...

Hi Zizhi,

I guess you are not familiar with kernel lingo so I will translate:
"...so I'd say go for it if there had been any change in the function
in question.  Same as with coding style, really..."

It means that your change is correct, but maintainers are
not interested in taking "style only" changes because it
creates undesired git history noise called "churn".

Should anyone be going to make logic changes in
mnt_get_write_access() in the future, the style change
can be applied along in the same patch.

One observation I have is -
If this was the only case that deviates from the standard
the change might have been justified.
>From a quick grep, I see that the reality in the code is very far
from this standard.

FWIW, wholeheartedly I agree that the ambiguity of the type of
an 'mnt' arg is annoying, but IMO 'm' is not making that very clear.
To me, 'mount' arg is very clear when it appears in the code.

Thanks,
Amir.