linux-kernel - Re: user-space concurrent pipe buffer scheduler interactions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <422feb1a-4b4e-45b6-838a-78e394dec9cc@metaparadigm.com>
Date: Thu, 4 Apr 2024 10:02:10 +1300
From: Michael Clark <michael@...aparadigm.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jens Axboe <axboe@...nel.dk>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: user-space concurrent pipe buffer scheduler interactions

On 4/4/24 09:39, Michael Clark wrote:
> So maybe it is possible to look at how many LOCK instructions were 
> retired in the last scheduler quantum ideally with retired-success, 
> retired-failed for interlocked-compare-and-swap. Maybe it is just a 
> performance counter and doesn't require perf tracing switched on?

just occurred to me that you could stash the address and width of the 
last failed interlocked-compare-and-swap to deduce wait-on-address or 
even ask the processor in some circumstances to generate a precise 
interrupt so that you could reschedule it. an idle thought. like if it 
is going to fail we might as well jump straight to the scheduler.