Re: [PATCH] generic/395: remove workarounds for wrong error codes

[Eric Biggers <ebiggers@kernel.org>]

On Sat, Oct 31, 2020 at 11:10:50AM -0700, Eric Biggers wrote:
> On Sat, Oct 31, 2020 at 01:34:39PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Oct 30, 2020 at 10:40:18PM -0700, Eric Biggers wrote:
> > > From: Eric Biggers <ebiggers@google.com>
> > > 
> > > generic/395 contains workarounds to allow for some of the fscrypt ioctls
> > > to fail with different error codes.  However, the error codes were all
> > > fixed up and documented years ago:
> > > 
> > > - FS_IOC_GET_ENCRYPTION_POLICY on ext4 failed with ENOENT instead of
> > >   ENODATA on unencrypted files.  Fixed by commit db717d8e26c2
> > >   ("fscrypto: move ioctl processing more fully into common code").
> > > 
> > > - FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of EEXIST
> > >   on encrypted files.  Fixed by commit 8488cd96ff88 ("fscrypt: use
> > >   EEXIST when file already uses different policy").
> > > 
> > > - FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of ENOTDIR
> > >   on nondirectories.  Fixed by commit dffd0cfa06d4 ("fscrypt: use
> > >   ENOTDIR when setting encryption policy on nondirectory").
> > > 
> > > It's been long enough, so update the test to expect the correct behavior
> > > only, so we don't accidentally reintroduce the wrong behavior.
> > > 
> > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > 
> > LGTM
> > 
> > Did these fixes get backported into the stable kernels (and the
> > relevant Android trees)?
> > 
> 
> Some of them.  Regarding stable kernels, currently if these 3 xfstests patches
> are applied, generic/395 will fail on 4.9 and earlier, generic/397 will fail on
> ubifs on 4.19 and earlier, and generic/398 will fail on 4.19 and earlier.
> 
> In Android kernels, the fscrypt support tends to be somewhat more up-to-date
> than in the corresponding LTS kernels, as the latest fscrypt-related patches
> were backported to them while they were open for development.  E.g., the latest
> 3.18, 4.4, and 4.9 Android common kernels have fs/crypto/ at the equivalent of
> upstream 4.17 or 4.18.  Those branches are closed for development though, so
> they won't be getting anything newer than that except through LTS.  (And devices
> using those kernel versions don't necessarily get kernel updates anymore.)
> 
> Backporting these patches can be tricky since the fscrypt code has changed a
> lot, so in most cases they would require writing custom backports.
> 
> So there's only so much I can do about older kernels.
> 
> But probably the most important patch I should backport to LTS is f5e55e777cc9
> ("fscrypt: return -EXDEV for incompatible rename or link into encrypted dir"),
> as that would get the tests passing on ext4 and f2fs on 4.14 and 4.19, and that
> patch was a fix for a bug that was causing problems for people.
> 

I ended up backporting some of the missing patches to some of the LTS kernels.

Now the status of the "encrypt" group tests is:

5.10-rc3: all pass, but generic/602 is flaky on ext4, which will be fixed by
          https://lkml.kernel.org/linux-fscrypt/20201109231151.GB853@sol.localdomain

5.4: all pass.

4.19: all pass since v4.19.155.

4.14: all pass on ext4 and f2fs since v4.14.204.  generic/{397,398,429} still
      fail on ubifs; it's hard to backport the needed patches to 4.14.

4.9: all pass on ext4 since v4.9.242 (not officially released yet).  generic/547
     still fails on f2fs due to a mysterious bug that causes dump.f2fs to not
     show the xattrs.  ubifs encryption wasn't supported yet.

4.4: generic/{395,397} still fail on ext4, and generic/{395,397,398,419,429,440}
     still fail on f2fs.  ubifs encryption wasn't supported yet.

- Eric