All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Potapenko <glider@google.com>
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>
Subject: Re: [PATCH -next 1/2] x86: crypto: kmsan: revert !KMSAN dependencies
Date: Wed, 14 Sep 2022 10:18:22 +0200	[thread overview]
Message-ID: <CAG_fn=XsmcKNi1Sg-HgP9Hh98mf910o0Uo4fCpwijiS_3adgyQ@mail.gmail.com> (raw)
In-Reply-To: <20220913175210.50945edb0738bf95300dc500@linux-foundation.org>

On Wed, Sep 14, 2022 at 2:52 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> 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 including
> > 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@google.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ße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

      reply	other threads:[~2022-09-14  8:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09  9:58 [PATCH -next 1/2] x86: crypto: kmsan: revert !KMSAN dependencies Alexander Potapenko
2022-09-09  9:58 ` [PATCH -next 2/2] crypto: x86: kmsan: disable accelerated configs in KMSAN builds Alexander Potapenko
2022-09-16  9:23   ` Alexander Potapenko
2022-09-18 21:45     ` Stephen Rothwell
2022-09-14  0:52 ` [PATCH -next 1/2] x86: crypto: kmsan: revert !KMSAN dependencies Andrew Morton
2022-09-14  8:18   ` Alexander Potapenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAG_fn=XsmcKNi1Sg-HgP9Hh98mf910o0Uo4fCpwijiS_3adgyQ@mail.gmail.com' \
    --to=glider@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiggers@kernel.org \
    --cc=elliott@hpe.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.