linux-kernel - Re: [PATCH RFC] locking: Add volatile to arch_spinlock

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:	Thu, 4 Dec 2014 11:18:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc:	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH RFC] locking: Add volatile to arch_spinlock_t structures

On Thu, Dec 4, 2014 at 10:36 AM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
>
> I have to ask...  Does this mean we can remove the current
> restrictions against 8-bit and 16-bit access from smp_load_acquire()
> and smp_store_release()?

I'd certainly be ok with it. Alpha doesn't have acquire/release
semantics anyway (really, it's the worst memory ordering model
*ever*), so those will end up being just plain (access-once) loads and
stores, followed/preceded by a memory barrier anyway. So it arguably
is no worse than the existing situation with ACCESS_ONCE() on alpha.

And quite frankly, I simply don't think that an old broken alpha
architecture should be something we worry about. Remember: the byte
and word ops were introduced in 21164, and released in 1996, so it's
not even like "alpha has broken behavior". It's literally just "the
very earliest alphas were broken", and I suspect most of those
machines (at least running Linux) weren't even SMP (ie somebody may
still have a Multia around for sentimental reasons, but SMP? No).

Of course, I'd like there to be a real reason to do so, not just "who
cares about really old alphas, nyaah, nyaah, nyaah"? But if there is a
clear case where a byte load-acquire and store-release would improve
on something important, then yes, I think we should do it.

We dropped support for the original i386, we can drop support for old
broken alphas. People running them for sentimental reasons might as
well be sentimental about software too, and run old kernels ;)

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/