linux-kernel - Re: [PATCH V2 11/19] csky: Atomic operations

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:   Fri, 6 Jul 2018 14:05:32 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Guo Ren <ren_guo@...ky.com>
Cc:     linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, daniel.lezcano@...aro.org,
        jason@...edaemon.net, arnd@...db.de, c-sky_gcc_upstream@...ky.com,
        gnu-csky@...tor.com, thomas.petazzoni@...tlin.com,
        wbx@...ibc-ng.org, green.hu@...il.com
Subject: Re: [PATCH V2 11/19] csky: Atomic operations

On Fri, Jul 06, 2018 at 07:48:12PM +0800, Guo Ren wrote:
> On Thu, Jul 05, 2018 at 08:00:08PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 02, 2018 at 01:30:14AM +0800, Guo Ren wrote:
> > > +#ifdef CONFIG_CPU_HAS_LDSTEX
> > > +ENTRY(csky_cmpxchg)
> > > +	USPTOKSP
> > > +	mfcr	a3, epc
> > > +	INCTRAP	a3
> > > +
> > > +	subi    sp, 8
> > > +	stw     a3, (sp, 0)
> > > +	mfcr    a3, epsr
> > > +	stw     a3, (sp, 4)
> > > +
> > > +	psrset	ee
> > > +1:
> > > +	ldex	a3, (a2)
> > > +	cmpne	a0, a3
> > > +	bt16	2f
> > > +	mov	a3, a1
> > > +	stex	a3, (a2)
> > > +	bez	a3, 1b
> > > +2:
> > > +	sync.is
> > > +	mvc	a0
> > > +	ldw	a3, (sp, 0)
> > > +	mtcr	a3, epc
> > > +	ldw     a3, (sp, 4)
> > > +	mtcr	a3, epsr
> > > +	addi	sp, 8
> > > +	KSPTOUSP
> > > +	rte
> > > +END(csky_cmpxchg)
> > > +#else
> > 
> > Please explain... if the CPU has LDEX/STEX, then _why_ do you need this?
> Our libc use csky_cmpxchg and we want it compatible. Of course, we'll
> also implement the ldex/stex atomic operations in libs in future.

I would strongly suggest not providing this syscall on SMP systems from
the get go. There is no point in starting with legacy problems without
an actual legacy.