Message ID | 20240116-flsplit-v1-1-c9d0f4370a5d@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-27874-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:42cf:b0:101:a8e8:374 with SMTP id q15csp499987dye; Tue, 16 Jan 2024 12:15:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IEe7VrS0lktF4uQP1pZBBAMt8IBkYU3J9qWFZjBg2FlruR5qIqmz+NmL+074ZoUXxYRxsL5 X-Received: by 2002:a19:5e56:0:b0:50e:7e1c:9049 with SMTP id z22-20020a195e56000000b0050e7e1c9049mr2342578lfi.70.1705436125631; Tue, 16 Jan 2024 12:15:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705436125; cv=pass; d=google.com; s=arc-20160816; b=eaHFJQDtKBzAGCdENm3IFNXaWPLqxI+jjVm6GvE8sX2nH/T8iBqLXZ5v4f7H54MVEQ S6MXwtGBQjAGkRMC9RYS5UPoyHr6JTBTZC1+BsE1Qz1uLlBReaKjoR+WfEZd+gi+mrAn c7cOcqG/Ud8UlnD4AjyVlIHy8Vw/xOvlGgPUR3ZRoq4x8DQXOXJEHla1kDcAIYnlaO6L fvq4F+e+L3CwHxNShqXiOPjWITbshm0amBjaI7K0yhVjg+AAwqZXXa0vsdMXrQWBKmzh 3RRAJj30jG2dmm0KVpnpWiA27uO50A7IVcmyYauaJvMNPyTHX586kIPr6DN1GEG+JiaT X9gw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=v2Kq9AsZ9ZvNG4iQor4PZYLk7II+wIIOk/Y2ckUbsT4=; fh=BsG+fS0IQ2XWS7DHljpBib1AecXP24VYAfT/lImgwa0=; b=isGY96vk45frretHdUZ1xgGVn0Yc+wT9w7nXwqfwKfXHHW43EoJ6DvSRL5NE3JJHP+ 1zgX2lZm6iZ334BrJ6uqXTS1GBMAvkmtv6uyIbe2gg6Kq2MFq8zlHFA1Q0Z3rQCxLyor gN8hMB81woZXVUtxp0ULxRuqKQxCdi7yUyDEY7iO6EY1Lv6PlGcCUMsMrQtPjFR+m2fv BDpJvh20eVYE0LQWvcTWoI+dAcDdm+wF2lwXUTd1S6M/2SaR4vOb4PgZwwDH6VLhRtY8 ifCzEWgUo8puBZBuB+wATBhyAVHxQBL98eTw/vSvSiNLYPkzz987q7gGRRTmxo8BRhND GiAw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cdIgnA3S; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-27874-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-27874-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id c16-20020a17090603d000b00a2c870b76dcsi4714698eja.484.2024.01.16.12.15.25 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 12:15:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-27874-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cdIgnA3S; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-27874-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-27874-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 4B2591F23E8C for <ouuuleilei@gmail.com>; Tue, 16 Jan 2024 20:15:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5E6FF6EB40; Tue, 16 Jan 2024 19:46:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cdIgnA3S" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 46AF46A343; Tue, 16 Jan 2024 19:46:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705434411; cv=none; b=EPDh47pLb8mUmPE3ew2h0XJGAtHcMh9ekvmQvJ8+loyN567dZVqk3Gp/vjYOaox2QAF3EMUoLLa/33HmKMG7XozgpS7lcRBIBIy9KUnw/rX6VmTgM1uG+/8snWUfMExm2yM7p6NAQ+u6hrsPn42ITIYO/iW3zZoOJthpqP8/DJA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705434411; c=relaxed/simple; bh=YjY34dM1H484nLiPhaWW57Fe2QttFCAJUqyuIWnNlwk=; h=Received:DKIM-Signature:From:Date:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id:References: In-Reply-To:To:Cc:X-Mailer:X-Developer-Signature:X-Developer-Key; b=NSYCohscd1I1IXFgwfzPGmpozHsjN+cO0IENNUOONGMs5KpfHT9/ZbQFr92vAn1UAXLoxcSQj7GNMk0pgnOFZ668gw5rRLtv1WPqdNgrepVeEROTrLmx2XqgB1pphRZYOAIyrti9eMpjSKHBLb8oJZJ7cwngsbyCW7ifplXqx9g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cdIgnA3S; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C20FC43394; Tue, 16 Jan 2024 19:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705434410; bh=YjY34dM1H484nLiPhaWW57Fe2QttFCAJUqyuIWnNlwk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=cdIgnA3S5spCJgft8bPEQ2cSRTib2CYHHHVTd9QZbp7rSSRir0PSNW/5pJArEoBOp CCG7ZV4Vty+k0+LnwzyzCXPuNbf/8D+kc0cn1XIGDhoEK0V9QjYdH3xj2RkTgSl2lb nKJxdH5EQfZYvkItb+H9yEGXstuSVAYobGuep5JUV2yLZ8cuGe8ISrjja2efG0L1CX eUBZRsaNMBemw6nMOEd0JDq6UsttMvH0N8yJg9jh2A5zGwnRNRN9QzvwuzO9M43y8K Epuiddlc0Ogss/9Cuf5AY5kKRT6sacFBhZXaU3FSGvGhrWvuz+Z1m0l7ChNftHZ5/j 4nucu9vZGs3EA== From: Jeff Layton <jlayton@kernel.org> Date: Tue, 16 Jan 2024 14:45:57 -0500 Subject: [PATCH 01/20] filelock: split common fields into struct file_lock_core Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240116-flsplit-v1-1-c9d0f4370a5d@kernel.org> References: <20240116-flsplit-v1-0-c9d0f4370a5d@kernel.org> In-Reply-To: <20240116-flsplit-v1-0-c9d0f4370a5d@kernel.org> To: Christian Brauner <brauner@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Eric Van Hensbergen <ericvh@kernel.org>, Latchesar Ionkov <lucho@ionkov.net>, Dominique Martinet <asmadeus@codewreck.org>, Christian Schoenebeck <linux_oss@crudebyte.com>, David Howells <dhowells@redhat.com>, Marc Dionne <marc.dionne@auristor.com>, Xiubo Li <xiubli@redhat.com>, Ilya Dryomov <idryomov@gmail.com>, Alexander Aring <aahringo@redhat.com>, David Teigland <teigland@redhat.com>, Miklos Szeredi <miklos@szeredi.hu>, Andreas Gruenbacher <agruenba@redhat.com>, Trond Myklebust <trond.myklebust@hammerspace.com>, Anna Schumaker <anna@kernel.org>, Chuck Lever <chuck.lever@oracle.com>, Neil Brown <neilb@suse.de>, Olga Kornievskaia <kolga@netapp.com>, Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>, Jan Kara <jack@suse.cz>, Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>, Joseph Qi <joseph.qi@linux.alibaba.com>, Steve French <sfrench@samba.org>, Paulo Alcantara <pc@manguebit.com>, Ronnie Sahlberg <lsahlber@redhat.com>, Shyam Prasad N <sprasad@microsoft.com>, Namjae Jeon <linkinjeon@kernel.org>, Sergey Senozhatsky <senozhatsky@chromium.org>, Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu <mhiramat@kernel.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org, gfs2@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-trace-kernel@vger.kernel.org, Jeff Layton <jlayton@kernel.org> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1316; i=jlayton@kernel.org; h=from:subject:message-id; bh=YjY34dM1H484nLiPhaWW57Fe2QttFCAJUqyuIWnNlwk=; b=owEBbQKS/ZANAwAIAQAOaEEZVoIVAcsmYgBlpt0grorncqc9kLnslpuIZeyPyWu2iH2b3i5B2 QhRt5u8LPSJAjMEAAEIAB0WIQRLwNeyRHGyoYTq9dMADmhBGVaCFQUCZabdIAAKCRAADmhBGVaC FbMvEACDnTZd0WkyKZFXw33wk0c2b7uo3MRrbTaAJ3SXB53MT5tXPsMrx/2rbi364MuRnoPP6bi Ys3m9vycKLXirGtEGtajbM2rYOPbebP7S9O+g1VFohLR1yLsN5joqExpg9aENC5dPj/lNHnSdr9 75WIVLpf7G0qyG78AxC9PJuPduxUntrA1wqjADiLA90eF1lozTSG9oLqgqpQ6VMOBwd0Kbs0a5i NDCVod8SRF0fiNddU9JOiAdT1FDgumShOCW9PUCd6uU5PV0N0dLx6JHt+7PTVPYoLT3lssNET7u VAWTej8G43paeJujEHZDrxniexM9BSVGH8c9xjv/H6lwcsOHrK2oYuNDvd7yDMty+3zHYgY62TT /hJ/tchNR3PxSGmvY+aeE4i7yty4fiJh0enq1fG/6/BPMvrpK0LqzHM/sLb4p8L0/7er89TolW/ 8m7NYvGWmzilgVDsLPfyaMzjOeP+YiFRh5XSrCh3Cq1tNsfW+6sr4MAucKQLcLXaxE2PQ/wXVP2 RVo6Q0PshEsg48lhuMGKOuyTjoKvVODmGMHNO92/xDemnCiZia4nc7lTSD8Px72ehl7408vGs6g amJflorwhY/bA5eWVETGdMDw7nt/06zb8dMl8qmXvG9sz/S54+3MvlnfNH842ZBqeaS3lrLhWLC n4OPtwY7WrvAqgw== X-Developer-Key: i=jlayton@kernel.org; a=openpgp; fpr=4BC0D7B24471B2A184EAF5D3000E684119568215 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788279390932377964 X-GMAIL-MSGID: 1788279390932377964 |
Series |
filelock: split struct file_lock into file_lock and file_lease structs
|
|
Commit Message
Jeff Layton
Jan. 16, 2024, 7:45 p.m. UTC
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@kernel.org>
---
include/linux/filelock.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Comments
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@kernel.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. Thanks, NeilBrown
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@kernel.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.
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;