lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aNNY1AzfGua3Kk3S@MiWiFi-R3L-srv>
Date: Wed, 24 Sep 2025 10:35:00 +0800
From: Baoquan He <bhe@...hat.com>
To: Andrey Konovalov <andreyknvl@...il.com>, snovitoll@...il.com
Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>, glider@...gle.com,
	dvyukov@...gle.com, elver@...gle.com, linux-mm@...ck.org,
	vincenzo.frascino@....com, akpm@...ux-foundation.org,
	kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
	kexec@...ts.infradead.org, sj@...nel.org,
	lorenzo.stoakes@...cle.com, christophe.leroy@...roup.eu
Subject: Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three
 modes

On 09/23/25 at 07:49pm, Andrey Konovalov wrote:
> On Mon, Sep 15, 2025 at 11:05 AM Baoquan He <bhe@...hat.com> wrote:
> >
> > > If you feel strongly that the ~1/8th RAM overhead (coming from the
> > > physmap shadow and the slab redzones) is still unacceptable for your
> > > use case (noting that the performance overhead (and the constant
> > > silent detection of false-positive bugs) would still be there), I
> > > think you can proceed with your series (unless someone else is
> > > against).
> >
> > Yeah, that would be great if we can also avoid any not needed memory
> > consumption for kdump.
> 
> Ack. Let's add support for kasan=off then.

Thanks.
> 
> But please describe it in detail in the KASAN documentation.

Will do in next round.

> 
> [...]
> 
> > When I made patch and posted, I didn't see Sabyrzhan's patches because I
> > usually don't go through mm mailing list. If I saw his patch earlier, I
> > would have suggested him to solve this at the same time.
> >
> > About Sabyrzhan's patch sereis, I have picked up part of his patches and
> > credit the author to Sabyrzhan in below patchset.
> >
> > [PATCH 0/4] mm/kasan: remove kasan_arch_is_ready()
> > https://lore.kernel.org/all/20250812130933.71593-1-bhe@redhat.com/T/#u
> >
> > About reposting of this series, do you think which one is preferred:
> >
> > 1) Firstly merge Sabyrzhan's patch series, I reverted them and apply for
> >    my patchset.
> >
> > 2) Credit the author of patch 1,2,3 of this patch series to Sabyrzhan
> >    too as below, because Sabyrzhan do the unification of the static keys
> >    usage and the KASAN initialization calls earlier:
> 
> Since the Sabyrzhan's patches are already in mm-stable (and I assume
> will be merged during the next merge window), just rebase your changes
> on top.

That's fine, I will rebase.

> 
> But also note that Sabyrzhan is planning to move out the
> kasan_enabled() checks into include/linux/kasan.h (which is a clean-up
> I would have also asked you to do with the kasan=off patches), so
> maybe you should sync up with him wrt these changes.

Hi Sabyrzhan,

What's your thought? You want to do the cleanup after my rebasing on
your merged patches or you prefer to do it ahead of time? Please let me
know so that I can adjust my posting accordingly. Thanks.

Thanks
Baoquan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ