linux-kernel - RE: [patch v3 24/36] Hexagon: Provide basic implementation and/or stubs for I/O routines.

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: <1315752415.455.47.camel@pasglop>
Date:	Sun, 11 Sep 2011 11:46:55 -0300
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Taylor Simpson <tsimpson@...eaurora.org>
Cc:	"'Arnd Bergmann'" <arnd@...db.de>,
	"'Linas Vepstas (Code Aurora)'" <linas@...eaurora.org>,
	"'Richard Kuo'" <rkuo@...eaurora.org>, linux-arch@...r.kernel.org,
	linux-hexagon@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: RE: [patch v3 24/36] Hexagon: Provide basic implementation and/or
 stubs for I/O routines.

On Sat, 2011-09-10 at 15:02 -0500, Taylor Simpson wrote:
> Using "memory" is a pretty big hammer.  Wouldn't it be better to use a
> memory operand?
>      asm volatile(
>              "memb(%0) = %1;"
>              : "m" (*(u8*)addr)
>              : "r" (data)
>      );

No you probably really want a full "memory" clobber, because typically
your IO ops should also act as barriers. The compiler has no way to know
for example that you want to order previous stores to memory (some DMA
descriptor you are populating) vs. an MMIO access that will trigger the
DMA from that location.

Linux defines the readX/writeX accessors as being fully ordered in that
case.

In fact, I'm not familiar with Hexagon, but if it's a weakly ordered
memory model you may also need some kind of memory barrier in those
accessors.

Cheers,
Ben.

> This may be a dumb question, but why do we need inline asm?  Why can't we
> write this with plain C code?
> /*
>  * writeb - write a byte to a memory location
>  * @data: data to write to
>  * @addr:  pointer to memory
>  *
>  */
> static inline void writeb(u8 data, volatile void __iomem *addr) {
> 	volatile u8 *ptr = (volatile u8*)addr;
> 	*ptr = data;
> }
> 
> 
> Taylor
> 
> 
> 
> -----Original Message-----
> From: linux-hexagon-owner@...r.kernel.org
> [mailto:linux-hexagon-owner@...r.kernel.org] On Behalf Of Arnd Bergmann
> Sent: Friday, September 09, 2011 4:13 PM
> To: Linas Vepstas (Code Aurora)
> Cc: Richard Kuo; linux-arch@...r.kernel.org; linux-hexagon@...r.kernel.org;
> linux-kernel@...r.kernel.org
> Subject: Re: [patch v3 24/36] Hexagon: Provide basic implementation and/or
> stubs for I/O routines.
> 
> On Friday 09 September 2011 14:14:13 Linas Vepstas wrote:
> > On Thu, Sep 08, 2011 at 08:09:11PM -0500, Richard Kuo wrote:
> > > +     asm volatile(
> > > +             "memb(%0) = %1;"
> > > +             :
> > > +             : "r" (addr), "r" (data)
> > > +     );
> > 
> > I'm kind-of vague on this, but I think that this also needs a
> > : "memory" at the end (to indicate that the asm snippet clobbers
> > memory), as otherwise the compiler may be tempted to reorder
> > these around other memory accesses. That is, the "volatile"
> > keyword is not enough (well, I'm not sure...), but I think
> > "volatile" only prevents the compiler from optimizing these
> > away completely, but is not enough to prevent unwanted
> > re-ordering.
> 
> Yes, absolutely correct. Specifically, this is required for the
> case where you first store values into regular memory and then
> use the writel() to trigger a DMA operation. Without the memory
> clobber, the dma may read from memory before the CPU has accessed
> it in case the store gets scheduled after the writel by the compiler.
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hexagon" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> 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/


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