From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com ([156.151.31.85]:60604 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbfFZPcL (ORCPT ); Wed, 26 Jun 2019 11:32:11 -0400 Date: Wed, 26 Jun 2019 08:30:36 -0700 From: "Darrick J. Wong" Subject: Re: [PATCH 1/5] vfs: create a generic checking and prep function for FS_IOC_SETFLAGS Message-ID: <20190626153036.GD5171@magnolia> References: <156151632209.2283456.3592379873620132456.stgit@magnolia> <156151633004.2283456.4175543089138173586.stgit@magnolia> <20190626040202.GA32272@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190626040202.GA32272@ZenIV.linux.org.uk> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Al Viro Cc: 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, Christoph Hellwig , linux-btrfs@vger.kernel.org On Wed, Jun 26, 2019 at 05:02:02AM +0100, Al Viro wrote: > On Tue, Jun 25, 2019 at 07:32:10PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong > > > > Create a generic function to check incoming FS_IOC_SETFLAGS flag values > > and later prepare the inode for updates so that we can standardize the > > implementations that follow ext4's flag values. > > Change in efivarfs behaviour deserves a note. I'm not saying it's wrong, > but behaviour is changed there - no-op FS_IOC_SETFLAGS used to fail > without CAP_LINUX_IMMUTABLE... Ok, will do. FWIW I wondered about fixing the orangefs usage too (using an unsigned long uval to hold the contents of an unsigned int coming from userspace) but ... that's their decision. --D