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

[Ard Biesheuvel]

On Thu, 14 Apr 2022 at 09:12, Eric Biggers <ebiggers at kernel.org> wrote:
>
> 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.
>

Fair enough.