linux-kernel - Re: [PATCH 3/6] arch/tile: support MMIO-based readb/writeb etc.

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]

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/