Re: [PATCH v4 00/21] btrfs: support idmapped mounts

[Christian Brauner <christian.brauner@ubuntu.com>]

On Mon, Aug 09, 2021 at 04:44:39PM +0200, David Sterba wrote:
> On Mon, Aug 02, 2021 at 02:28:27PM +0200, Christian Brauner wrote:
> > On Tue, Jul 27, 2021 at 12:48:39PM +0200, Christian Brauner wrote:
> > > From: Christian Brauner <christian.brauner@ubuntu.com>
> > > 
> > > Hey everyone,
> > > 
> > > /* v4 */
> > > Rename new helper to lookup_one() and add new Reviewed-bys.
> > > 
> > > This series enables the creation of idmapped mounts on btrfs. On the list of
> > > filesystems btrfs was pretty high-up and requested quite often from userspace
> > > (cf. [1]). This series requires just a few changes to the vfs for specific
> > > lookup helpers that btrfs relies on to perform permission checking when looking
> > > up an inode. The changes are required to port some other filesystem as well.
> > > 
> > > The conversion of the necessary btrfs internals was fairly straightforward. No
> > > invasive changes were needed. I've decided to split up the patchset into very
> > > small individual patches. This hopefully makes the series more readable and
> > > fairly easy to review. The overall changeset is quite small.
> > > 
> > > All non-filesystem wide ioctls that peform permission checking based on inodes
> > > can be supported on idmapped mounts. There are really just a few restrictions.
> > > This should really only affect the deletion of subvolumes by subvolume id which
> > > can be used to delete any subvolume in the filesystem even though the caller
> > > might not even be able to see the subvolume under their mount. Other than that
> > > behavior on idmapped and non-idmapped mounts is identical for all enabled
> > > ioctls. People interested in idmappings on idmapped mounts should read [2].
> > > 
> > > The changeset has an associated new testsuite specific to btrfs. The
> > > core vfs operations that btrfs implements are covered by the generic
> > > idmapped mount testsuite. For the ioctls a new testsuite was added. It
> > > is sent alongside this patchset for ease of review but will very likely
> > > be merged independent of it.
> > > 
> > > All patches are based on v5.14-rc3.
> > > 
> > > The series can be pulled from:
> > > https://git.kernel.org/brauner/h/fs.idmapped.btrfs
> > > https://github.com/brauner/linux/tree/fs.idmapped.btrfs
> > > 
> > > The xfstests can be pulled from:
> > > https://git.kernel.org/brauner/xfstests-dev/h/fs.idmapped.btrfs
> > > https://github.com/brauner/xfstests/tree/fs.idmapped.btrfs
> > > 
> > > Note, the new btrfs xfstests patch is on top of a branch of mine
> > > containing a few more preliminary patches. So if you want to run the
> > > tests, please simply pull the branch and build from there.
> > > 
> > > The series has been tested with xfstests including the newly added btrfs
> > > specific test. All tests pass.
> > > There were three unrelated failures that I observed: btrfs/219,
> > > btrfs/2020 and btrfs/235. All three also fail on earlier kernels
> > > without the patch series applied.
> > 
> > Hey David,
> > 
> > Sorry to ping, could I answer the outstanding questions you had and are
> > you okay with this series?
> 
> I'll need to do one more pass but I don't remember any big issues or
> anything that couldn't be adjusted later. This is going to be the last
> nontrivial patchset, time is almost up for next merge window code
> freeze.
> 
> Patch 1, the VFS part, does not have acks but for inclusion into
> for-next I don't think it's necessary. I'll let you know once I push the
> idmap branch to for-next so you can drop the patch.

Ok, sounds good. I wasn't sure if you wanted to base your branch on the
tag or just carry it yourself. Whatever works best.

Christian