linux-kernel - RE: [PATCH V2] MIPS: implement smp_cond_load

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:   Wed, 11 Jul 2018 10:04:52 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Paul Burton' <paul.burton@...s.com>,
        Peter Zijlstra <peterz@...radead.org>,
        陈华才 <chenhc@...ote.com>
CC:     Ralf Baechle <ralf@...ux-mips.org>,
        James Hogan <jhogan@...nel.org>,
        linux-mips <linux-mips@...ux-mips.org>,
        Fuxin Zhang <zhangfx@...ote.com>,
        wuzhangjin <wuzhangjin@...il.com>,
        stable <stable@...r.kernel.org>,
        "Alan Stern" <stern@...land.harvard.edu>,
        Andrea Parri <andrea.parri@...rulasolutions.com>,
        Will Deacon <will.deacon@....com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Akira Yokosawa <akiyks@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3

From: Paul Burton
> Sent: 10 July 2018 18:11
...
> I'm not sure which is the intent (I can ask if someone's interested),
> but you could either:
> 
>   1) Consider the store buffer a cache, in which case loads need to
>      check all store buffers from all CPUs because of the "all caches"
>      part of the first quoted sentence.
> 
> or
> 
>   2) Decide store buffers aren't covered by the MIPS architecture
>      documentation at all in which case the only sane thing to do would
>      be to make it transparent to software (and here Loongson's isn't)
...

Store buffers are common and are never transparent to multi-threaded code.
They are largely why you need locks.

At least on (early) sparc systems they were between the execution unit
and the data cache.

I also suspect that 'write starvation' is also common - after all the
purpose of the store buffer is to do reads in preference to writes in
order to reduce the cpu stalls waiting for the memory bus (probably
the cpu to cache interface).

I think your example is just:
	*(volatile int *)xxx = 1;
	while (!*(volatile int *)yyy) continue;
running on two cpu with xxx and yyy swapped?

You need a stronger bus cycle in there somewhere.

	David