linux-kernel - Re: [PATCH] filelock: add stubs for new functions when CONFIG_FILE

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: <26f4a293f9139a495ef86e3b0e2a98abfa1679b8.camel@kernel.org>
Date: Mon, 05 Feb 2024 07:20:18 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Al Viro <viro@...iv.linux.org.uk>, Chuck Lever <chuck.lever@...cle.com>,
  linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, kernel test
 robot <lkp@...el.com>
Subject: Re: [PATCH] filelock: add stubs for new functions when
 CONFIG_FILE_LOCKING=n

On Mon, 2024-02-05 at 13:10 +0100, Christian Brauner wrote:
> > Another thought too: "locks_" as a prefix is awfully generic. Might it be
> > better to rename these new functions with a "filelock_" prefix instead?
> > That would better distinguish to the casual reader that this is dealing
> > with a file_lock object. I'm happy to respin the set if that's the
> > consensus.
> 
> If it's just a rename then just point me to a branch I can pull. I don't
> think it's worth resending just because you effectively did some variant
> of s/lock_*/filelock_*/g
> 
> In any case, folded this one.

Thanks!

I haven't done a rename (yet). I was just trying to feel out whether it
was worthwhile. At this point, I'm thinking I'll just leave them as-is.,
but let me know if anyone has opinions to the contrary.
-- 
Jeff Layton <jlayton@...nel.org>