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: <20150602121227.GA1474@macpro.local>
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

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")
- "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:
  "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."

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


Luc Van Oostenryck
--
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/