From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C1AFC47089 for ; Fri, 25 Nov 2022 03:49:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229684AbiKYDtQ (ORCPT ); Thu, 24 Nov 2022 22:49:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbiKYDtQ (ORCPT ); Thu, 24 Nov 2022 22:49:16 -0500 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D82B26117; Thu, 24 Nov 2022 19:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=I2TD8YnyUVRKaNNBGvfs3pUWZDwIFw5kNMaApqkurhc=; b=LNV2e8UbAEOQw/T25Fn0zcJFtt fNpKOR7AmYQmyKebyHLdQkC/VRgO+jC6IaDUeHAjw4EL0DsbkFM6Iqc2wV96JeHEovMJKBTXDZmhv ZBw2xsCMnqYGB42wL+ylBtaiFvmXn4+q48vjcw+DG90eOjgZU2/9rcOSLcqiIsrxuWaDw1SMMEzx7 t7JkkxZCAEJ97Erz/o4KvknT6QpkedMLh6PAKj8gLWbA+2hlrTJV8E/LgdR9rDoShxcJCoTpm912V ABkJ97xsSUr6RQZKyn8cXzXou9+2BUXYywgtCMyz0UPAL3QT8v6w4dSbpiqIhsoN4SGRxmTtMbclh leUGm6UQ==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1oyPhG-006aFN-28; Fri, 25 Nov 2022 03:48:14 +0000 Date: Fri, 25 Nov 2022 03:48:14 +0000 From: Al Viro To: Jeff Layton 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 Subject: Re: [PATCH] filelock: move file locking definitions to separate header file Message-ID: References: <20221120210004.381842-1-jlayton@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221120210004.381842-1-jlayton@kernel.org> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org On Sun, Nov 20, 2022 at 03:59:57PM -0500, Jeff Layton wrote: > --- /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 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" > +struct lock_manager_operations { > + void *lm_mod_owner; > + fl_owner_t (*lm_get_owner)(fl_owner_t); Probably take fl_owner_t to some more neutral header... > +#define locks_inode(f) file_inode(f) Why do we still have that one, anyway? Separate patch, obviously, but I would take Occam's Razor to that entity... > +struct files_struct; > +extern void show_fd_locks(struct seq_file *f, > + struct file *filp, struct files_struct *files); If anything, that would be better off as fl_owner_t... Again, a separate patch. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Date: Fri, 25 Nov 2022 03:48:14 +0000 Subject: [Cluster-devel] [PATCH] filelock: move file locking definitions to separate header file In-Reply-To: <20221120210004.381842-1-jlayton@kernel.org> References: <20221120210004.381842-1-jlayton@kernel.org> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, Nov 20, 2022 at 03:59:57PM -0500, Jeff Layton wrote: > --- /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 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" > +struct lock_manager_operations { > + void *lm_mod_owner; > + fl_owner_t (*lm_get_owner)(fl_owner_t); Probably take fl_owner_t to some more neutral header... > +#define locks_inode(f) file_inode(f) Why do we still have that one, anyway? Separate patch, obviously, but I would take Occam's Razor to that entity... > +struct files_struct; > +extern void show_fd_locks(struct seq_file *f, > + struct file *filp, struct files_struct *files); If anything, that would be better off as fl_owner_t... Again, a separate patch. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aib29ajc245.phx1.oracleemaildelivery.com (aib29ajc245.phx1.oracleemaildelivery.com [192.29.103.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0C2BBC6370B for ; Sat, 26 Nov 2022 18:13:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=oss-phx-1109; d=oss.oracle.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=pda11jOTDAFHomSEYHTalg5kaszTvko3I5AjSF3nfkI=; b=ctm8N4Fkb2w2cH4rTtEtID3BCZ3MNaLxwKCMMXozfW3fy5dzBw+cHM/IBRd9bfYIZUnsjcGumr5w Do2DbBkV0Fw72KXl2C2c7JRxAHEJay0PtuCNuTG2FZ/CoyCx7t5X1IPzEZI8UzVccGGxWXSV3Bdj 6KwrLznAMtw8IptX1bh+0uNFeUFPRfD7pY8Rp/nhuBa5V/8BaRdq+lxWEWY+5Qw77YwfqvPV/mWN lgzlirUMVQRk6evvvEQRjsQ/E3vnFdwVqXj7cGg6CgYsLJwmlUL920K1AnKRjQNS4qR6ReA12Ero v4diqXo3WxFMUMlg9/fLMtfgyp1LjuVTrPiFpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=prod-phx-20191217; d=phx1.rp.oracleemaildelivery.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=pda11jOTDAFHomSEYHTalg5kaszTvko3I5AjSF3nfkI=; b=r2RgM9j6tnH6kau1ARoF79v7QsMWyK7o7iKVpYOYnspT2BLwyBQnjM1nytFCKN7x7wJNppY/iVC9 VAJyq60JgEGi733YzhspmO4Ja5dGPG96kDB3N3eDhfiaa/XKiyvECnU3uEIrzDAeeCJUDCffd78D Ohpyzoa54gRNhrPKfo3lV1MRdVXm+JAI1STVk3Y61yC1CNCtM4duKDMbAq59VkC/yJT1fCnFLrXb 2+nYEgRT+fes3DADYEdVAE4z2SYB2+gZKq83N9En8snpu+Ro2y/t2psjlaZlg3kwzqfyru+PcnZ8 Z4mz/UAaPX4HGuFnOb2HIL4CjwbJuD7T7nuJdA== Received: by omta-ad1-fd1-102-us-phoenix-1.omtaad1.vcndpphx.oraclevcn.com (Oracle Communications Messaging Server 8.1.0.1.20221104 64bit (built Nov 4 2022)) with ESMTPS id <0RLY0075BVZ16190@omta-ad1-fd1-102-us-phoenix-1.omtaad1.vcndpphx.oraclevcn.com> for ocfs2-devel@archiver.kernel.org; Sat, 26 Nov 2022 18:13:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=I2TD8YnyUVRKaNNBGvfs3pUWZDwIFw5kNMaApqkurhc=; b=LNV2e8UbAEOQw/T25Fn0zcJFtt fNpKOR7AmYQmyKebyHLdQkC/VRgO+jC6IaDUeHAjw4EL0DsbkFM6Iqc2wV96JeHEovMJKBTXDZmhv ZBw2xsCMnqYGB42wL+ylBtaiFvmXn4+q48vjcw+DG90eOjgZU2/9rcOSLcqiIsrxuWaDw1SMMEzx7 t7JkkxZCAEJ97Erz/o4KvknT6QpkedMLh6PAKj8gLWbA+2hlrTJV8E/LgdR9rDoShxcJCoTpm912V ABkJ97xsSUr6RQZKyn8cXzXou9+2BUXYywgtCMyz0UPAL3QT8v6w4dSbpiqIhsoN4SGRxmTtMbclh leUGm6UQ==; Date: Fri, 25 Nov 2022 03:48:14 +0000 To: Jeff Layton Message-id: References: <20221120210004.381842-1-jlayton@kernel.org> MIME-version: 1.0 Content-disposition: inline In-reply-to: <20221120210004.381842-1-jlayton@kernel.org> X-Source-IP: 62.89.141.173 X-Proofpoint-Virus-Version: vendor=nai engine=6500 definitions=10541 signatures=596816 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 adultscore=0 bulkscore=0 spamscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 phishscore=0 clxscore=-10 lowpriorityscore=0 malwarescore=0 mlxlogscore=728 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211250028 Cc: Latchesar Ionkov , Martin Brandenburg , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , linux-xfs@vger.kernel.org, Mike Marshall , linux-cifs@vger.kernel.org, Andreas Gruenbacher , Miklos Szeredi , linux-afs@lists.infradead.org, cluster-devel@redhat.com, Christine Caulfield , v9fs-developer@lists.sourceforge.net, Ilya Dryomov , Namjae Jeon , devel@lists.orangefs.org, Shyam Prasad N , Eric Van Hensbergen , Tom Talpey , linux-fsdevel@vger.kernel.org, ceph-devel@vger.kernel.org, Xiubo Li , Trond Myklebust , linux-nfs@vger.kernel.org, Paulo Alcantara , samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Steve French , Sergey Senozhatsky , Chuck Lever , Anna Schumaker , Bob Peterson , ocfs2-devel@oss.oracle.com Subject: Re: [Ocfs2-devel] [PATCH] filelock: move file locking definitions to separate header file X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Al Viro via Ocfs2-devel Reply-to: Al Viro Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Errors-to: ocfs2-devel-bounces@oss.oracle.com X-ServerName: zeniv.linux.org.uk X-Proofpoint-SPF-Result: None X-Spam: Clean X-Proofpoint-GUID: M4IhSeQJ1OaxRMUckCY27Q0ycCyFrILr X-Proofpoint-ORIG-GUID: M4IhSeQJ1OaxRMUckCY27Q0ycCyFrILr X-Mailman-Approved-At: Sat, 26 Nov 2022 18:13:43 +0000 Reporting-Meta: AAF8K8Q7KWTIDIicEyKapnY9M5qe6l2np/VIU0GUtewJuzO0tLhdcog4rgNIQeJX +emZOK60LzW3oNw3catBHhyHXT/Pvq2OrW7VvLE6vOOCy5s7eogT6C3ougGyKtzR egEyfGOsaXd7L9MWKQqUtXOqlS2L4ebv23hVdEcmvIRU2DXYnVTLGFzG1J/90u/Q b9hm2nEG8Mc+XwJAfoN8Eu8QhtltJ+9TztbBrrIusU1U1kk9iMdmQ4ibJamXYiy5 NoDzoyXTqh1XQ4Q6sdEFNNmmn6lGj7ikap0n8Reto+vef0hDMfa6AaE5zr3Ezb6J FIh/jmD1cd02ul0O3JtNt24NUCAQI5hAERLP22KZrOxwmANSdEHzaexA/qdS6Ahk y+YrZACt70vn4joUXYEXU2WpxwVQGV+PAlWRVVuBG4NXVBoI7gP6wC4fuI4NDH+z Z1KxZ+YWL9Wr8rPq1kDBn5a5dM8/3ILG62MPhikWy62gYM2efAkW73gXXF5JDT/a Y9JsjjJIhQLqkkKgxzl08TQBHpopXmjTsWDXbNip6cmn On Sun, Nov 20, 2022 at 03:59:57PM -0500, Jeff Layton wrote: > --- /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 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" > +struct lock_manager_operations { > + void *lm_mod_owner; > + fl_owner_t (*lm_get_owner)(fl_owner_t); Probably take fl_owner_t to some more neutral header... > +#define locks_inode(f) file_inode(f) Why do we still have that one, anyway? Separate patch, obviously, but I would take Occam's Razor to that entity... > +struct files_struct; > +extern void show_fd_locks(struct seq_file *f, > + struct file *filp, struct files_struct *files); If anything, that would be better off as fl_owner_t... Again, a separate patch. _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel