Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220412172816.917723-1-nhuck@google.com> <20220412172816.917723-9-nhuck@google.com>
 <YlZpUijo/1nJp0Bw@sol.localdomain> <CAMj1kXH1C8W6Cxa7jTZ8_h3L4_Xefwv2=r1JRNva101CvWWsjw@mail.gmail.com>
 <YlfJYwwCukoGuLek@sol.localdomain>
In-Reply-To: <YlfJYwwCukoGuLek@sol.localdomain>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Thu, 14 Apr 2022 09:15:42 +0200
Message-ID: <CAMj1kXGS_vtcgZSB5qXt4dekTb51FeZ7yMWbtu8-DrvFU39ogA@mail.gmail.com>
Subject: Re: [PATCH v4 8/8] fscrypt: Add HCTR2 support for filename encryption
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Nathan Huckleberry <nhuck@google.com>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Paul Crowley <paulcrowley@google.com>,
        Sami Tolvanen <samitolvanen@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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