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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 12 Jul 2022 10:46:22 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org,
        Waiman Long <longman@...hat.com>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH 06/13] locking/qspinlock: merge qspinlock_paravirt.h into
 qspinlock.c

Excerpts from Peter Zijlstra's message of July 6, 2022 3:36 am:
> On Tue, Jul 05, 2022 at 07:20:37PM +0200, Peter Zijlstra wrote:
>> On Tue, Jul 05, 2022 at 12:38:13AM +1000, Nicholas Piggin wrote:
>> > There isn't much reason to keep these separate.
>> 
>> The reason was so that other paravirt implementations could be added.
>> 
>> The CNA thing was also implemented this way...
> 
> Also, (TIL) s390 seems to have a copy of all this:
> 
>   b96f7d881ad9 ("s390/spinlock: introduce spinlock wait queueing")

Right. powerpc is going to add another one. I've also been struggling
to make PV qspinlock work well for us and the PV hooks didn't quite
help. This series is just me dumping what I had done while working
with the code until now, feel free to take or leave it.

The PV things could easily be moved out again or conditionally
compiled when another implementation in tree comes up.

> it might be nice if it were possible to fold that back into this with a
> different paravirt implementation; but I've not looked at it in any
> great detail yet.

I would like to fold powerpc some time (or at least merge it with
s390 which it is possibly more similar with) but at the moment kind
of need prove it even works on our systems  and solves issues before
bothering other archs with it. It's not all that complicated though
so not too concerned about carrying it in arch.

https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-July/245977.html

Thanks,
Nick

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ