Re: [PATCH v4 8/8] fscrypt: Add HCTR2 support for filename encryption

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Apr 13, 2022 at 08:16:25AM +0200, Ard Biesheuvel wrote:
> > > diff --git a/tools/include/uapi/linux/fscrypt.h b/tools/include/uapi/linux/fscrypt.h
> > > index 9f4428be3e36..a756b29afcc2 100644
> > > --- a/tools/include/uapi/linux/fscrypt.h
> > > +++ b/tools/include/uapi/linux/fscrypt.h
> > > @@ -27,7 +27,8 @@
> > >  #define FSCRYPT_MODE_AES_128_CBC             5
> > >  #define FSCRYPT_MODE_AES_128_CTS             6
> > >  #define FSCRYPT_MODE_ADIANTUM                        9
> > > -/* If adding a mode number > 9, update FSCRYPT_MODE_MAX in fscrypt_private.h */
> > > +#define FSCRYPT_MODE_AES_256_HCTR2           10
> > > +/* If adding a mode number > 10, update FSCRYPT_MODE_MAX in fscrypt_private.h */
> > >
> >
> > As far as I know, you don't actually need to update the copy of UAPI headers in
> > tools/.  The people who maintain those files handle that.  It doesn't make sense
> > to have copies of files in the source tree anyway.
> >
> 
> Doesn't the x86 build emit a warning if these go out of sync?

The warning is emitted when building tools/perf/, not the kernel itself.

According to https://lore.kernel.org/r/20191001185741.GD13904@kernel.org, the
perf maintainers actually prefer that their files are *not* updated for them.
And I'd like to push back against having duplicate source files in the tree
anyway, for obvious reasons.  So I think we shouldn't update this file.

- Eric