linux-kernel - Re: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC

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]

Date:   Fri, 19 May 2017 15:15:53 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     peterz@...radead.org
Cc:     babu.moger@...cle.com, mingo@...hat.com, arnd@...db.de,
        shannon.nelson@...cle.com, haakon.bugge@...cle.com,
        steven.sistare@...cle.com, vijay.ac.kumar@...cle.com,
        jane.chu@...cle.com, sparclinux@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC

From: Peter Zijlstra <peterz@...radead.org>
Date: Fri, 19 May 2017 11:03:02 +0200

> On Thu, May 18, 2017 at 10:31:13PM -0400, David Miller wrote:
>> From: Babu Moger <babu.moger@...cle.com>
>> Date: Thu, 18 May 2017 18:36:08 -0600
>> 
>> > @@ -82,6 +82,7 @@ config SPARC64
>> >  	select HAVE_ARCH_AUDITSYSCALL
>> >  	select ARCH_SUPPORTS_ATOMIC_RMW
>> >  	select HAVE_NMI
>> > +	select ARCH_USE_QUEUED_RWLOCKS
>> >  
>> 
>> If you are selecting this on SPARC64 all the time, then:
>> 
>> > @@ -94,6 +94,7 @@ static inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long fla
>> >  	: "memory");
>> >  }
>> >  
>> > +#ifndef CONFIG_QUEUED_RWLOCKS
>> >  /* Multi-reader locks, these are much saner than the 32-bit Sparc ones... */
>> 
>> You can remove this segment of ifdef'd code altogether since it is in
>> a sparc64 specific header file.
> 
> 
> So IIRC Sparc v8 only has that single byte load-and-set (or swap)
> instruction, right? That means you can only make test-and-set spinlocks
> and then have to build the world on top of that.
> 
> I don't see qrwlock -- which assumes the spinlock implementation is fair
> -- making much sense for that.
> 
> Also, IIRC Sparc-v8 didn't really have very big SMP systems, those came
> with v9. And qspinlock only really makes sense on the bigger systems
> (not to mention that building the qspinlock on top of atomic operations
> build on test-and-set spinlocks just seems extremely dysfunctional).
> 
> 
> In any case, I think what I'm saying is that it makes sense to make this
> a Sparcv9 only feature.

I agree with you, there is no reason to try and support
queued locks on 32-bit sparc.

However, I don't see what any of this has to do with the feedback
I was giving the patch author :-)