linux-kernel - Re: [PATCH] mm: avoid use of BIT() macro for initialising VMA flags

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: <CAGudoHFcD=Wv=SEqaaks1TcY2CZQsozNzadejQA1uBbdNPSakg@mail.gmail.com>
Date: Wed, 10 Dec 2025 23:44:48 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, David Laight <david.laight.linux@...il.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, David Hildenbrand <david@...nel.org>, 
	"Liam R . Howlett" <Liam.Howlett@...cle.com>, Mike Rapoport <rppt@...nel.org>, 
	Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, oliver.sang@...el.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: avoid use of BIT() macro for initialising VMA flags

On Wed, Dec 10, 2025 at 5:18 PM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> On Tue, Dec 09, 2025 at 10:26:22AM +0100, Mateusz Guzik wrote:
> > On Tue, Dec 09, 2025 at 09:28:10AM +0100, Vlastimil Babka wrote:
> > > As Mateusz pointed out off-list, the profiles look like mutexes are doing
> > > less optimistic spinning and more sleeping. Which IMHO isn't something that
> > > this change can directly affect.
> > >
> >
> > Not mutexes but rwsems.
> >
> > The bench at hand has some of the code spinlocked, other parts take
> > rwsems for reading *or* writing.
> >
> > I had a peek at rwsem implementation and to my understanding it can
> > degrade to no spinning in a microbenchmark setting like this one,
> > provided you are unlucky enough.
>
> So we're just sleep, sleep sleeping? That would explain it...
>
> I mean is this an issue with the IPC design or the rwsem's in general?
>

the ipc code is not doing itself any favors, but is probably not worth
working on either

the lock stuff suffers internal problems. while there is no such thing
as fastest possible lock, let alone sleepable rw lock, it is pretty
clear the current code leaves perf on the table even with that caveat

> >
> > In particular you can get unlucky if existing timings get perturbed,
> > which I presume is happening after Lorenzo's patch.
> >
> > To demonstrate I wrote a toy patch which conditionally converts affected
> > down_read calls into down_write (inlined at the end).
> >
> > While the original report is based on a 192-thread box, I was only able
> > to test with 80 threads. Even so, the crux of the issue was nicely
> > reproduced.
> >
> > ./stress-ng --timeout 10 --times --verify --metrics --no-rand-seed --msg 80
>
> I wonder if large core count matters here in particular, I was doing this
> (albeit in a VM...) with 62 cores
>

you need a large enough count to generate enough contention in the
first place. how much is it for this bench i have no tried figuring
out, even for my hw