Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp10531217rwb; Fri, 25 Nov 2022 05:35:01 -0800 (PST) X-Google-Smtp-Source: AA0mqf4Vzk11+icF2gTDoIUeDzYqHO5hIi4/8ipsADF9RyKKerV47ICm+A3ZrqUb6SxAmZirz49E X-Received: by 2002:a17:906:f2cb:b0:78d:e645:9f7d with SMTP id gz11-20020a170906f2cb00b0078de6459f7dmr30615954ejb.572.1669383300920; Fri, 25 Nov 2022 05:35:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669383300; cv=none; d=google.com; s=arc-20160816; b=vOBDziC/LOZAO/CUpWqOiAg2jWvy+EG+aZKrYqOw9yEPP6UxmJfA9I+qBmuoNXvBUW JmNK1BGCKSXl3KiBoigsyvrqZ17RswzAygPTFW2kNwIA9nhY+lV+DKLBVESgP1wiYdcV AO6CkTpbaxS3lL0zPLaafv637AaerHSUUe4xPHGqz/aCNfoHK/bl4KCC6b+KWblWQuz/ KNfVhDCOsIWq51iirlE14ydo+d8vv8TQztwIPO/p4pNCccmnNjbik9BAJirEmrqAOrqT PQnzgWuG/H10e8mRRYmmDZdTTgCRKrx3zMEaSiLZvZsk2RhObPyPvVFuBlmtxC9YXeAz hlDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=Ohsolls9DG7p4nHgUl8d/8tWg3FXUi0ogi48k3T7g60=; b=SsUrlA6VFITg82e/DWOl7MYAYw/BLe+MZgrXl7nk/fD/bLkYoYwKhhkNE8gWGx5OJP jUgYrsDORLQXYYx6A5RbMcpe3pfaEw/xdDEeGtsJh1Hlb8kmFMt52xtwORhpl9RK2sz1 8zAu3beyJoogNxTdICS1Bcd9V1as7SsblKNq7w0y8HMQX+VhhxeV3ypAetuTMCPZ/pep xU/wdAH6D8Pui2rMLx3YbptCf6o2X9iTKMTRg1RVbVB5GwV5967PEkz7QWmRqLOQ7WI6 wPpnqIRhJKpqI77AOv34D0z5TBfiBsQeOae3JOurD5EwusrZzNGI2mN61/MHcdA7bO8T AXnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ITYmgIWG; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id vr9-20020a170907a50900b007ae9fc42919si2805192ejc.907.2022.11.25.05.34.23; Fri, 25 Nov 2022 05:35:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ITYmgIWG; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229538AbiKYNX4 (ORCPT + 99 others); Fri, 25 Nov 2022 08:23:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbiKYNXz (ORCPT ); Fri, 25 Nov 2022 08:23:55 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACCC940931; Fri, 25 Nov 2022 05:23:51 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 490D5623FB; Fri, 25 Nov 2022 13:23:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC855C433C1; Fri, 25 Nov 2022 13:23:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669382630; bh=EGJ1sbVmh8zfuee638fIF/XO+8/weuDlINdqpi5zZtE=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=ITYmgIWGeb/7tfCFFc4kVDpIzqmupq1CVJap5fhBl/OT/PtkT4fvz+47vLok2k5y+ 9CRsV+JeWA0KEW85LVZu0FSIZep4yXbkGkq4EGBqpjWl9J4R07ZmdftvaN+jO6GvVh UV+8CnZQsig9drGP5ocCBKCwdeh2CEjv01ouksVCHxKjEnYvQ0VQOwyYDVIftWVHKE GsZuPwqfzHVqHsCgI2NSiNlqWlCXseI+0MB2Oq49i12gvBk+OTgmkxmQgpHo2z4CO0 KgxgBErlyuKDTZUoexdSzNPrYs0i7nPI8jo2JLFO4nl05cBpvzph4ae7XpMCDCSp+4 bOGw2Qy+6YgWg== Message-ID: <1d474f53670771f324745f597ec94b63a006d687.camel@kernel.org> Subject: Re: [PATCH] filelock: move file locking definitions to separate header file From: Jeff Layton To: Al Viro Cc: Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , Xiubo Li , Ilya Dryomov , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Christine Caulfield , David Teigland , Chuck Lever , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Namjae Jeon , Sergey Senozhatsky , Trond Myklebust , Anna Schumaker , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , "Darrick J. Wong" , hch@lst.de, linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, devel@lists.orangefs.org, linux-xfs@vger.kernel.org Date: Fri, 25 Nov 2022 08:23:45 -0500 In-Reply-To: References: <20221120210004.381842-1-jlayton@kernel.org> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.1 (3.46.1-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, 2022-11-25 at 03:48 +0000, Al Viro wrote: > On Sun, Nov 20, 2022 at 03:59:57PM -0500, Jeff Layton wrote: >=20 > > --- /dev/null > > +++ b/include/linux/filelock.h > > @@ -0,0 +1,428 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _LINUX_FILELOCK_H > > +#define _LINUX_FILELOCK_H > > + > > +#include > > +#include >=20 > Umm... I'd add a comment along the lines of "struct file_lock has > a BS union by fs type; NFS side of things needs nfs_fs_i.h" >=20 Ok. > > +struct lock_manager_operations { > > + void *lm_mod_owner; > > + fl_owner_t (*lm_get_owner)(fl_owner_t); >=20 > Probably take fl_owner_t to some more neutral header... >=20 I left it in fs.h for now. Some of the file_operations prototypes need that typedef, and I figure that anyone who is including filelock.h will almost certainly need to include fs.h anyway. We could move it into a separate header too, but it's probably not worth it. HCH mentioned years ago though that we should just get rid of fl_owner_t altogether and just use 'void *'. I didn't do it at the time because I was focused on other changes, but this might be a good time to change it. > > +#define locks_inode(f) file_inode(f) >=20 > Why do we still have that one, anyway? Separate patch, obviously, > but I would take Occam's Razor to that entity... >=20 I can spin up a patch to nuke that too. I count only 30 callsites remaining anyway. > > +struct files_struct; > > +extern void show_fd_locks(struct seq_file *f, > > + struct file *filp, struct files_struct *files); >=20 > If anything, that would be better off as fl_owner_t... Again, a separate > patch. I'm not sure what you mean here. This prototype hasn't changed, and is only called from procfs. --=20 Jeff Layton