From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Wed, 26 Jun 2019 08:43:02 -0700 Subject: [Cluster-devel] [PATCH 2/5] vfs: create a generic checking function for FS_IOC_FSSETXATTR In-Reply-To: <20190626153542.GE5171@magnolia> References: <156151632209.2283456.3592379873620132456.stgit@magnolia> <156151633829.2283456.834142172527987802.stgit@magnolia> <20190626041133.GB32272@ZenIV.linux.org.uk> <20190626153542.GE5171@magnolia> Message-ID: <20190626154302.GA31445@infradead.org> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Jun 26, 2019 at 08:35:42AM -0700, Darrick J. Wong wrote: > > static inline void simple_fill_fsxattr(struct fsxattr *fa, unsigned xflags) > > { > > memset(fa, 0, sizeof(*fa)); > > fa->fsx_xflags = xflags; > > } > > > > and let the compiler optimize the crap out? > > The v2 series used to do that, but Christoph complained that having a > helper for a two-line memset and initialization was silly[1] so now we > have this version. > > I don't mind reinstating it as a static inline helper, but I'd like some > input from any of the btrfs developers (or you, Al) about which form is > preferred. I complained having that helper in btrfs. I think Al wants a generic one, which at least makes a little more sense. That being said I wonder if we should lift these attr ioctls to file op methods and deal with all that crap in VFS code instead of having all those duplicated ioctl parsers. 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 X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E57DEC48BD3 for ; Wed, 26 Jun 2019 15:43:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF9732177B for ; Wed, 26 Jun 2019 15:43:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="JiqZyiWj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728204AbfFZPnr (ORCPT ); Wed, 26 Jun 2019 11:43:47 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:49636 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725958AbfFZPnr (ORCPT ); Wed, 26 Jun 2019 11:43:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DVYqe3tpQ8e1sMTCWOSh9xLpYFRFLHE+hBBBu6gUiVY=; b=JiqZyiWjMhOWaBcr2IrbgLkM4 0syeulFERs2blphfx8J9OQQYfDcD66MEDA/eYqMG3YlVaiNtVmnfwdsQ65mUOa5tobSAjIu4o0moB 8ozOmeOpYAerFJ54x2vEzjiR8SfnDfyWG+bdR1ZUOZNrlL/SYacZFBNxtNQ7BkGu8CuE2RuIHDLu+ CaRHYuI+HSdl81J/22Qtg+UiLTkGUTCTPoK9RgIw1FJLZsPC0ZS5UU4A0RQGMZLPHDKHcZxxfrX3Z j7RrqvM1qVcwEiIAm5WRBQmOct/BZjqliivvm1uRzpyKv/GzpK/wBw3vN8gt+E6H+zEEVMvM/k0vT MgqmUKwSQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.92 #3 (Red Hat Linux)) id 1hgA4c-0000SB-CS; Wed, 26 Jun 2019 15:43:02 +0000 Date: Wed, 26 Jun 2019 08:43:02 -0700 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Al Viro , matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, shaggy@kernel.org, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, jk@ozlabs.org, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, cluster-devel@redhat.com, jfs-discussion@lists.sourceforge.net, linux-efi@vger.kernel.org, Jan Kara , reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH 2/5] vfs: create a generic checking function for FS_IOC_FSSETXATTR Message-ID: <20190626154302.GA31445@infradead.org> References: <156151632209.2283456.3592379873620132456.stgit@magnolia> <156151633829.2283456.834142172527987802.stgit@magnolia> <20190626041133.GB32272@ZenIV.linux.org.uk> <20190626153542.GE5171@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190626153542.GE5171@magnolia> User-Agent: Mutt/1.11.4 (2019-03-13) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, Jun 26, 2019 at 08:35:42AM -0700, Darrick J. Wong wrote: > > static inline void simple_fill_fsxattr(struct fsxattr *fa, unsigned xflags) > > { > > memset(fa, 0, sizeof(*fa)); > > fa->fsx_xflags = xflags; > > } > > > > and let the compiler optimize the crap out? > > The v2 series used to do that, but Christoph complained that having a > helper for a two-line memset and initialization was silly[1] so now we > have this version. > > I don't mind reinstating it as a static inline helper, but I'd like some > input from any of the btrfs developers (or you, Al) about which form is > preferred. I complained having that helper in btrfs. I think Al wants a generic one, which at least makes a little more sense. That being said I wonder if we should lift these attr ioctls to file op methods and deal with all that crap in VFS code instead of having all those duplicated ioctl parsers. 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 X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58593C48BD6 for ; Wed, 26 Jun 2019 15:43:48 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2CA4F2177B; Wed, 26 Jun 2019 15:43:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="Wrc3c3Pj"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="DQD9+rVW"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="JiqZyiWj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2CA4F2177B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hgA59-000804-FR; Wed, 26 Jun 2019 15:43:35 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hgA58-0007zi-H7; Wed, 26 Jun 2019 15:43:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DVYqe3tpQ8e1sMTCWOSh9xLpYFRFLHE+hBBBu6gUiVY=; b=Wrc3c3PjdFvz74KH1kSO9Nhhaw 0waAJRO+U6BfuFNsAjnJtg79ziyFunycwbJ7OjyslXxHwfaMTT1/evlZ/uW61zDpve6/DHMWlWcSY kL+NIbB/bE4kibVHcFJE5qrFweIPlu1kxlqxzt2wWcpxxUL5rxmc6pz0NmU/79Cefz68=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DVYqe3tpQ8e1sMTCWOSh9xLpYFRFLHE+hBBBu6gUiVY=; b=DQD9+rVW0G9aLRnxIlq+P74uKD xe0tCCfzKE05KYgfef+PCxDjhPeSdWE1q61K0L6Xj1MCQNaq72JptC0nfDaqm2y68K+52yF6hDFBz eS8JRDHujl067YA6l1efAEYQa0b3msRGWLeIHSquhX0iVbTbnUxU3aadCsnuzB2c0lE4=; Received: from bombadil.infradead.org ([198.137.202.133]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1hgA5H-00Es49-Ep; Wed, 26 Jun 2019 15:43:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DVYqe3tpQ8e1sMTCWOSh9xLpYFRFLHE+hBBBu6gUiVY=; b=JiqZyiWjMhOWaBcr2IrbgLkM4 0syeulFERs2blphfx8J9OQQYfDcD66MEDA/eYqMG3YlVaiNtVmnfwdsQ65mUOa5tobSAjIu4o0moB 8ozOmeOpYAerFJ54x2vEzjiR8SfnDfyWG+bdR1ZUOZNrlL/SYacZFBNxtNQ7BkGu8CuE2RuIHDLu+ CaRHYuI+HSdl81J/22Qtg+UiLTkGUTCTPoK9RgIw1FJLZsPC0ZS5UU4A0RQGMZLPHDKHcZxxfrX3Z j7RrqvM1qVcwEiIAm5WRBQmOct/BZjqliivvm1uRzpyKv/GzpK/wBw3vN8gt+E6H+zEEVMvM/k0vT MgqmUKwSQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.92 #3 (Red Hat Linux)) id 1hgA4c-0000SB-CS; Wed, 26 Jun 2019 15:43:02 +0000 Date: Wed, 26 Jun 2019 08:43:02 -0700 From: Christoph Hellwig To: "Darrick J. Wong" Message-ID: <20190626154302.GA31445@infradead.org> References: <156151632209.2283456.3592379873620132456.stgit@magnolia> <156151633829.2283456.834142172527987802.stgit@magnolia> <20190626041133.GB32272@ZenIV.linux.org.uk> <20190626153542.GE5171@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190626153542.GE5171@magnolia> User-Agent: Mutt/1.11.4 (2019-03-13) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Headers-End: 1hgA5H-00Es49-Ep Subject: Re: [f2fs-dev] [PATCH 2/5] vfs: create a generic checking function for FS_IOC_FSSETXATTR X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: shaggy@kernel.org, jfs-discussion@lists.sourceforge.net, linux-efi@vger.kernel.org, Jan Kara , hch@infradead.org, linux-btrfs@vger.kernel.org, clm@fb.com, adilger.kernel@dilger.ca, matthew.garrett@nebula.com, linux-nilfs@vger.kernel.org, cluster-devel@redhat.com, linux-ext4@vger.kernel.org, josef@toxicpanda.com, reiserfs-devel@vger.kernel.org, Al Viro , dsterba@suse.com, jaegeuk@kernel.org, tytso@mit.edu, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, jk@ozlabs.org, jack@suse.com, linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Wed, Jun 26, 2019 at 08:35:42AM -0700, Darrick J. Wong wrote: > > static inline void simple_fill_fsxattr(struct fsxattr *fa, unsigned xflags) > > { > > memset(fa, 0, sizeof(*fa)); > > fa->fsx_xflags = xflags; > > } > > > > and let the compiler optimize the crap out? > > The v2 series used to do that, but Christoph complained that having a > helper for a two-line memset and initialization was silly[1] so now we > have this version. > > I don't mind reinstating it as a static inline helper, but I'd like some > input from any of the btrfs developers (or you, Al) about which form is > preferred. I complained having that helper in btrfs. I think Al wants a generic one, which at least makes a little more sense. That being said I wonder if we should lift these attr ioctls to file op methods and deal with all that crap in VFS code instead of having all those duplicated ioctl parsers. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 2/5] vfs: create a generic checking function for FS_IOC_FSSETXATTR Date: Wed, 26 Jun 2019 08:43:02 -0700 Message-ID: <20190626154302.GA31445@infradead.org> References: <156151632209.2283456.3592379873620132456.stgit@magnolia> <156151633829.2283456.834142172527987802.stgit@magnolia> <20190626041133.GB32272@ZenIV.linux.org.uk> <20190626153542.GE5171@magnolia> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G3T8Xo3Jak9o4HNdG+z7LyikCnZoqGeuuyfmLa8mkaI=; b=ghi6yFk3P9QqXx 5VkdWwABwCRjzHnPW1A9t2t20N8lsS+f50zFVuJFWG8260KKYTBMi4EOhTzvMHSmFlc3YlRZZu0Mh dL7w7VGJG0odlag4nrN7+Z1VswmeyLmYHMe/eq8drADCm0p5k4AR/ME9vggEVOda9zgzf49zwIf8m uFZlHpKzSiBGFpk9cvFZKY7LU0l0bB/t0CX+2VjnP7Z/3eoaNRYYlFPgrhyJIp2obDRl2e+tbApjC HI0t6uSgs+SGx7t32joDu6TkR7nxoNxSWOwAJB8r6+Fmr53bSZxfwwZ6oNmdgqqzHDLaqD3czBA0u 0JIOSiBe2Piyfo1ucNYQ==; Content-Disposition: inline In-Reply-To: <20190626153542.GE5171@magnolia> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org To: "Darrick J. Wong" Cc: shaggy@kernel.org, jfs-discussion@lists.sourceforge.net, linux-efi@vger.kernel.org, Jan Kara , hch@infradead.org, linux-btrfs@vger.kernel.org, yuchao0@huawei.com, clm@fb.com, adilger.kernel@dilger.ca, matthew.garrett@nebula.com, linux-nilfs@vger.kernel.org, cluster-devel@redhat.com, linux-ext4@vger.kernel.org, josef@toxicpanda.com, reiserfs-devel@vger.kernel.org, Al Viro , dsterba@suse.com, jaegeuk@kernel.org, tytso@mit.edu, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, jk@ozlabs.org, jack@suse.com, linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com On Wed, Jun 26, 2019 at 08:35:42AM -0700, Darrick J. Wong wrote: > > static inline void simple_fill_fsxattr(struct fsxattr *fa, unsigned xflags) > > { > > memset(fa, 0, sizeof(*fa)); > > fa->fsx_xflags = xflags; > > } > > > > and let the compiler optimize the crap out? > > The v2 series used to do that, but Christoph complained that having a > helper for a two-line memset and initialization was silly[1] so now we > have this version. > > I don't mind reinstating it as a static inline helper, but I'd like some > input from any of the btrfs developers (or you, Al) about which form is > preferred. I complained having that helper in btrfs. I think Al wants a generic one, which at least makes a little more sense. That being said I wonder if we should lift these attr ioctls to file op methods and deal with all that crap in VFS code instead of having all those duplicated ioctl parsers. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Wed, 26 Jun 2019 08:43:02 -0700 Subject: [Ocfs2-devel] [PATCH 2/5] vfs: create a generic checking function for FS_IOC_FSSETXATTR In-Reply-To: <20190626153542.GE5171@magnolia> References: <156151632209.2283456.3592379873620132456.stgit@magnolia> <156151633829.2283456.834142172527987802.stgit@magnolia> <20190626041133.GB32272@ZenIV.linux.org.uk> <20190626153542.GE5171@magnolia> Message-ID: <20190626154302.GA31445@infradead.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Darrick J. Wong" Cc: Al Viro , matthew.garrett@nebula.com, yuchao0@huawei.com, tytso@mit.edu, shaggy@kernel.org, ard.biesheuvel@linaro.org, josef@toxicpanda.com, hch@infradead.org, clm@fb.com, adilger.kernel@dilger.ca, jk@ozlabs.org, jack@suse.com, dsterba@suse.com, jaegeuk@kernel.org, cluster-devel@redhat.com, jfs-discussion@lists.sourceforge.net, linux-efi@vger.kernel.org, Jan Kara , reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org On Wed, Jun 26, 2019 at 08:35:42AM -0700, Darrick J. Wong wrote: > > static inline void simple_fill_fsxattr(struct fsxattr *fa, unsigned xflags) > > { > > memset(fa, 0, sizeof(*fa)); > > fa->fsx_xflags = xflags; > > } > > > > and let the compiler optimize the crap out? > > The v2 series used to do that, but Christoph complained that having a > helper for a two-line memset and initialization was silly[1] so now we > have this version. > > I don't mind reinstating it as a static inline helper, but I'd like some > input from any of the btrfs developers (or you, Al) about which form is > preferred. I complained having that helper in btrfs. I think Al wants a generic one, which at least makes a little more sense. That being said I wonder if we should lift these attr ioctls to file op methods and deal with all that crap in VFS code instead of having all those duplicated ioctl parsers.