linux-kernel - Re: [PATCH v2 28/76] ARC: I/O and DMA Mappings

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]

Message-Id: <201301211426.26839.arnd@arndb.de>
Date:	Mon, 21 Jan 2013 14:26:26 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 28/76] ARC: I/O and DMA Mappings

On Monday 21 January 2013, Vineet Gupta wrote:
> On Friday 18 January 2013 09:25 PM, Arnd Bergmann wrote:
> > ...
> So the comment above can be deleted, and we probably need a check in
> ioremap_prot() so that early ioremap bails out if called early - probably using
> slab_is_available()

Ok.

> >> +#include <asm-generic/io.h>
> > I think I commented before that asm-generic/io.h has a number of
> > problems and you should at least override the __raw_{read,write}{b,w,l,q}
> > functions with your own ones using inline assembly.
> >
> > You should also define a non-NULL PCI_IOBASE.
> 
> Sorry for missing out on this one - this was indeed suggested in the private
> pre-list review you did. The 64-bit version certainly needs to be wrapped in a irq
> safe block.
> 
> However others will be exactly same as generic ones. Given that these routines
> operate on __iomem memory which has to be uncached: either wired in uncached
> address space, or goes via an uncached MMU mapping, IMHO the inline-asm or 'C'
> version won't add any value. We do have uncached LD/ST, I've tried to avoid them
> so far as they have certain micro-architectural quirks and per previous argument
> it seems they would be redundant.
> 
> Having said that I might be over-looking something important - so please let me know.

We just moved ARM to use inline assembly versions here, because there were bugs
with some gcc versions and undefined C code in the kernel using 'packed' pointers,
as well as problems in KVM interpreting the memory accessor instructions. I would
definetely recommend doing inline assembly for these on all architectures to spare
you trouble later.

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