linux-kernel - Re: [PATCH 20/28] ARCv2: barriers

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:	Tue, 23 Jun 2015 13:32:17 +0530
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	Will Deacon <will.deacon@....com>
CC:	Peter Zijlstra <peterz@...radead.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>
Subject: Re: [PATCH 20/28] ARCv2: barriers

On Monday 22 June 2015 07:06 PM, Will Deacon wrote:
>> OK, so given that regular/mmio is also weakly ordered, it would seem that we need
>> > full mb() *before* and *after* the IO access in the non relaxed API. ARM code
>> > seems to put a rmb() after the readl and wmb() before the writel. Is that based on
>> > how h/w provides for some ?
> We figured that you'd likely be doing something like:
> 
> <writel_relaxed DMA buffer>
> <writel MMIO "go" reg>
> 
> or:
> 
> <readl MMIO "status" reg>
> <readl_relaxed DMA buffer>
> 
> so ended up with writel doing {wmb(); writel_relaxed} and readl doing
> {readl_relaxed; rmb()}.
> 
>> > In one of the links you posted above, Catalin posed the same question, but I
>> > didn't see response to that.
>> > 
>> > | If we are to make the writel/readl on ARM fully ordered with both IO
>> > | (enforced by hardware) and uncached memory, do we add barriers on each
>> > | side of the writel/readl etc.? The common cases would require a barrier
>> > | before writel (write buffer flushing) and a barrier after readl (in case
>> > | of polling for a "DMA complete" state).
>> > |
>> > | So if io_wmb() just orders to IO writes (writel_relaxed), does it mean
>> > | that we still need a mighty wmb() that orders any type of accesses (i.e.
>> > | uncached memory vs IO)? Can drivers not use the strict writel() and no
>> > | longer rely on wmb() (wondering whether we could simplify it on ARM with
>> > | fully ordered IO accessors)?
>> > 
>> > Further readl/writel would be no different than ioread32/iowrite32 ?
> ioread32/iowrite32 can be used with port addresses and dispatch to the
> relevant accessors depending on that. The memory ordering semantics should
> be the same as readl/writel.
> 
>> > FWIW, h/w folks tell me that DMB guarentess local barrier semantics so we don't
>> > need to use DSYNC. Latter only provides full r+w+TLB/BPU stuff while DMB allows
>> > finer grained r/w/r+w. But if we need full mb then using one vs. other becomes a
>> > moot point.
> I'd say go with what we do on ARM/arm64, then at least we have consistency
> in the use of barriers.

Thx for very helpful review/feedback Will. I've posted a v2 !

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