linux-kernel - Re: [PATCH 1/3] MIPS: R6: Use lightweight SYNC instruction in smp

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]

Message-ID: <20150602124400.GG29986@linux-mips.org>
Date:	Tue, 2 Jun 2015 14:44:01 +0200
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Luc Van Oostenryck <luc.vanoostenryck@...il.com>
Cc:	Paul Burton <paul.burton@...tec.com>,
	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
	linux-mips@...ux-mips.org, benh@...nel.crashing.org,
	will.deacon@....com, linux-kernel@...r.kernel.org,
	markos.chandras@...tec.com, macro@...ux-mips.org,
	Steven.Hill@...tec.com, alexander.h.duyck@...hat.com,
	davem@...emloft.net
Subject: Re: [PATCH 1/3] MIPS: R6: Use lightweight SYNC instruction in smp_*
 memory barriers

On Tue, Jun 02, 2015 at 02:12:29PM +0200, Luc Van Oostenryck wrote:
> Date:   Tue, 2 Jun 2015 14:12:29 +0200
> From: Luc Van Oostenryck <luc.vanoostenryck@...il.com>
> To: Paul Burton <paul.burton@...tec.com>
> Cc: Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
>  linux-mips@...ux-mips.org, benh@...nel.crashing.org, will.deacon@....com,
>  linux-kernel@...r.kernel.org, ralf@...ux-mips.org,
>  markos.chandras@...tec.com, macro@...ux-mips.org, Steven.Hill@...tec.com,
>  alexander.h.duyck@...hat.com, davem@...emloft.net
> Subject: Re: [PATCH 1/3] MIPS: R6: Use lightweight SYNC instruction in
>  smp_* memory barriers
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Jun 02, 2015 at 11:08:35AM +0100, Paul Burton wrote:
> > Hi Leonid,
> > 
> 
> <snip>
> 
> > > +
> > > +	  If that instructions are not implemented in processor then it is
> > > +	  converted to generic "SYNC 0".
> > 
> > I think this would read better as something like:
> > 
> >   If a processor does not implement the lightweight sync operations then
> >   the architecture requires that they interpret the corresponding sync
> >   instructions as the typical heavyweight "sync 0". Therefore this
> >   should be safe to enable on all CPUs implementing release 2 or
> >   later of the MIPS architecture.
> > 
> 
> Is it really the case for release 2?
> 
> I'm asking because recently I needed to do something similar and I couldn't
> find this garantee in the revision 2.00 of the manual.
> May it's just poorly formulated but here is what I find in it:
> - "The stype values 1-31 are reserved for future extensions to the architecture."
>   (ok)
> - "A value of zero will always be defined such that it performs all defined
>    synchronization operations." (ok)
> - "Non-zero values may be defined to remove some synchronization operations."
>   (ok, certainly if we understand the word "weaker" instead of "remove")

Yes, "weaker" is what was meant here.

> - "As such, software should never use a non-zero value of the stype field, as
>   this may inadvertently cause future failures if non-zero values remove
>   synchronization operations." (Mmmm, ok but ...)
> Nowhere is there something close to what is found in the revision 5.0 or later:

I think that's just a very convoluted way to say non-zero values are
reserved and the CPU may bite you and your kittens if you dare to use
such values.

>   "If an implementation does not use one of these non-zero values to define a
>    different synchronization behavior, then that non-zero value of stype must
>    act the same as stype zero completion barrier."

"We try to be nice to bad code but ... you've been warned!" :-)

> The wording may have changed since revision 2.8 but I don't have access to the
> corresponding manual.

The page about the SYNC instruction has changed significantly over time -
the SYNC instruction's documentation manual has grown from one page for the
R4000 to four pages for MIPS32 R1 and R2.5 to five pages for MIPS64 R3.02
and newer.  R3 added read, write, rw, acquire and release sync types.

But the sentence in question exists unchanged even in the R6 manual.

  Ralf
--
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/