On Wed, Sep 14, 2022 at 2:52 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 9 Sep 2022 11:58:10 +0200 Alexander Potapenko <glider@xxxxxxxxxx> 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@xxxxxxxxxx/ 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@xxxxxxxxxx/ and https://lore.kernel.org/all/20220909095811.2166073-2-glider@xxxxxxxxxx/ 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
