linux-kernel - Re: [PATCH 01/20] filelock: split common fields into struct file_lock

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]

Date: Wed, 17 Jan 2024 07:46:48 -0500
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neilb@...e.de>
Cc: Christian Brauner <brauner@...nel.org>, Alexander Viro
 <viro@...iv.linux.org.uk>, Eric Van Hensbergen <ericvh@...nel.org>, 
 Latchesar Ionkov <lucho@...kov.net>, Dominique Martinet
 <asmadeus@...ewreck.org>, Christian Schoenebeck <linux_oss@...debyte.com>,
 David Howells <dhowells@...hat.com>, Marc Dionne
 <marc.dionne@...istor.com>, Xiubo Li <xiubli@...hat.com>, Ilya Dryomov
 <idryomov@...il.com>, Alexander Aring <aahringo@...hat.com>, David Teigland
 <teigland@...hat.com>, Miklos Szeredi <miklos@...redi.hu>, Andreas
 Gruenbacher <agruenba@...hat.com>, Trond Myklebust
 <trond.myklebust@...merspace.com>,  Anna Schumaker <anna@...nel.org>, Chuck
 Lever <chuck.lever@...cle.com>, Olga Kornievskaia <kolga@...app.com>, Dai
 Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,  Jan Kara
 <jack@...e.cz>, Mark Fasheh <mark@...heh.com>, Joel Becker
 <jlbec@...lplan.org>, Joseph Qi <joseph.qi@...ux.alibaba.com>, Steve French
 <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>, Ronnie Sahlberg
 <lsahlber@...hat.com>, Shyam Prasad N <sprasad@...rosoft.com>, Namjae Jeon
 <linkinjeon@...nel.org>, Sergey Senozhatsky <senozhatsky@...omium.org>,
 Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
 linux-kernel@...r.kernel.org, v9fs@...ts.linux.dev, 
 linux-afs@...ts.infradead.org, ceph-devel@...r.kernel.org,
 gfs2@...ts.linux.dev,  linux-fsdevel@...r.kernel.org,
 linux-nfs@...r.kernel.org,  ocfs2-devel@...ts.linux.dev,
 linux-cifs@...r.kernel.org,  samba-technical@...ts.samba.org,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH 01/20] filelock: split common fields into struct
 file_lock_core

On Wed, 2024-01-17 at 09:07 +1100, NeilBrown wrote:
> On Wed, 17 Jan 2024, Jeff Layton wrote:
> > In a future patch, we're going to split file leases into their own
> > structure. Since a lot of the underlying machinery uses the same fields
> > move those into a new file_lock_core, and embed that inside struct
> > file_lock.
> > 
> > Signed-off-by: Jeff Layton <jlayton@...nel.org>
> > ---
> >  include/linux/filelock.h | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/filelock.h b/include/linux/filelock.h
> > index 95e868e09e29..7825511c1c11 100644
> > --- a/include/linux/filelock.h
> > +++ b/include/linux/filelock.h
> > @@ -85,8 +85,9 @@ bool opens_in_grace(struct net *);
> >   *
> >   * Obviously, the last two criteria only matter for POSIX locks.
> >   */
> > -struct file_lock {
> > -	struct file_lock *fl_blocker;	/* The lock, that is blocking us */
> > +
> > +struct file_lock_core {
> > +	struct file_lock *fl_blocker;	/* The lock that is blocking us */
> >  	struct list_head fl_list;	/* link into file_lock_context */
> >  	struct hlist_node fl_link;	/* node in global lists */
> >  	struct list_head fl_blocked_requests;	/* list of requests with
> > @@ -102,6 +103,10 @@ struct file_lock {
> >  	int fl_link_cpu;		/* what cpu's list is this on? */
> >  	wait_queue_head_t fl_wait;
> >  	struct file *fl_file;
> > +};
> > +
> > +struct file_lock {
> > +	struct file_lock_core fl_core;
> >  	loff_t fl_start;
> >  	loff_t fl_end;
> >  
> 
> If I we doing this, I would rename all the fields in file_lock_core to
> have an "flc_" prefix, and add some #defines like
> 
>  #define fl_list fl_core.flc_list
> 
> so there would be no need to squash this with later patches to achieve
> bisectability.
> 
> The #defines would be removed after the coccinelle scripts etc are
> applied.
> 
> I would also do the "convert some internal functions" patches *before*
> the bulk conversion of fl_foo to fl_code.flc_foo so that those functions
> don't get patched twice.
> 
> But this is all personal preference.  If you prefer your approach,
> please leave it that way.  The only clear benefit of my approach is that
> you don't need to squash patches together, and that is probably not a
> big deal.
> 

I considered going back and doing that. It would allow me to break this
up into smaller patches, but I think that basically means doing all of
this work over again. I'll probably stick with this approach, unless I
end up needing to respin for other reasons.

-- 
Jeff Layton <jlayton@...nel.org>