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: <4F834C48.1060603@tilera.com>
Date:	Mon, 9 Apr 2012 16:53:28 -0400
From:	Chris Metcalf <cmetcalf@...era.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/6] arch/tile: support MMIO-based readb/writeb etc.

On 4/9/2012 9:24 AM, Arnd Bergmann wrote:
> On Friday 06 April 2012, Chris Metcalf wrote:
>> Add support for MMIO read/write on tilegx to support GXIO IORPC access.
>> Similar to the asm-generic version, but we include memory fences on
>> the writes to be conservative.
>>
>> Signed-off-by: Chris Metcalf <cmetcalf@...era.com>
> It's usually better to use inline assembly here, to guarantee that
> the compiler does not split an access into multiple byte sized
> accesses as it might sometimes do if a register data structure
> is marged "packed". The "volatile" guarantees that the access
> does not go beyond a single word, but it does not guarantee that
> it's atomic.

Good point.  Since tile doesn't support unaligned reads in kernel space
anyway, it hadn't occurred to me, but you're right that the compiler might
be too conservative in some circumstances.  Fixed.

> I don't think you need the fences after the write because PCI MMIO
> writes are posted anyway (only PIO is non-posted), but you might need
> some kind of barrier on the read to prevent a scenario where an MMIO 
> read tells you that a DMA has completed, but the CPU (or the compiler)
> has scheduled the read of that data ahead of the MMIO read.

I'm not sure why posted vs non-posted would matter, but I think you're
right that we shouldn't need them, and some simple testing seemed to show
that the system was stable without them.  The initial developer said they
were there originally just there for reasons of paranoia during development.

Thanks!

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ