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: <20220909095811.2166073-1-glider@google.com> <20220913175210.50945edb0738bf95300dc500@linux-foundation.org>
In-Reply-To: <20220913175210.50945edb0738bf95300dc500@linux-foundation.org>
From:   Alexander Potapenko <glider@google.com>
Date:   Wed, 14 Sep 2022 10:18:22 +0200
Message-ID: <CAG_fn=XsmcKNi1Sg-HgP9Hh98mf910o0Uo4fCpwijiS_3adgyQ@mail.gmail.com>
Subject: Re: [PATCH -next 1/2] x86: crypto: kmsan: revert !KMSAN dependencies
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Robert Elliott <elliott@hpe.com>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Linux Crypto List <linux-crypto@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-next <linux-next@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Sep 14, 2022 at 2:52 AM Andrew Morton <akpm@linux-foundation.org> w=
rote:
>
> On Fri,  9 Sep 2022 11:58:10 +0200 Alexander Potapenko <glider@google.com=
> wrote:
>
> > This patch reverts "crypto: Kconfig: fix up for "crypto: kmsan: disable
> > accelerated configs under KMSAN" used by Stephen Rothwell to cleanly
> > merge KMSAN patches into linux-next.
> >
> > Because now arch-specific crypto configs reside in a separate Kconfig
> > file, we can disable them all by adding a single !KMSAN before includin=
g
> > that file (done in the following patch).
> >
> > Among others, this patch reverts !KMSAN check for
> > CONFIG_CRYPTO_AEGIS128_SIMD, which is ARM-only and is hence unnecessary=
,
> > because KMSAN does not support ARM yet.
>
> As I understand it, these patches are against linux-next and only
> linux-next because they pertain to linux-next's resolution of conflicts
> between the MM tree and the crypto tree?

The thing is that this patch only makes sense with its counterpart
that adds a !KMSAN condition on "source arch/x86/crypto/Kconfig", and
the latter file is missing in the -mm tree.

> I'm not sure how to handle that, even if anyone wants to.  How about
> you send an update to
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm's mm-unstable
> branch so the code which is there makes sense?  Then we'll ask Stephen
> to redo the crypto tree resolution?

Because the crypto tree is moving code crypto/Kconfig to
arch/x86/crypto/Kconfig, we'll still need to apply these two patches
to the result of the crypto tree merge.

I was going to send out the updated patch series anyway (there are
minor improvements to the core which let us drop "kmsan: unpoison @tlb
in arch_tlb_gather_mmu()", also there's a new test case).
I could drop "crypto: kmsan: disable accelerated configs under KMSAN"
from it, so that it would be possible to enable accelerated configs
under KMSAN at the cost of false positives (which are only visible if
one builds with KMSAN).
Then, once arch/x86/crypto/Kconfig hits -mm, I can send the remaining
patch that disables accelerated crypto under KMSAN:
https://lore.kernel.org/all/20220909095811.2166073-2-glider@google.com/

Or I could just send v7 patches against mm-unstable and ask Stephen to
apply both https://lore.kernel.org/all/20220909095811.2166073-2-glider@goog=
le.com/
and https://lore.kernel.org/all/20220909095811.2166073-2-glider@google.com/
at merge time.

Which option is better?


--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Stra=C3=9Fe, 33
80636 M=C3=BCnchen

Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg