Prohibit ioremap() on kernel managed RAM
RFC 1/1 Prohibit ioremap() on kernel managed RAM
ARMv6 and above have a restriction whereby aliasing virtual:physical mappings must not have differing memory type and sharability attributes. Strictly, this covers the memory type (strongly ordered, device, memory), cache attributes (uncached, write combine, write through, write back read alloc, write back write alloc) and the shared bit.
However, using ioremap() and its variants on system RAM results in mappings which differ in these attributes from the main system RAM mapping. Other architectures which similar restrictions approch this problem in the same way - they do not permit ioremap on main system RAM.
Make ARM behave in the same way, with a WARN_ON() such that users can be traced and an alternative approach found.
arch/arm/mm/ioremap.c +6 -0
@@ -268,6 +268,12 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,if (pfn >=0x100000 && (__pfn_to_phys (pfn) & ~SUPERSECTION_MASK ))return NULL ; +/* +* Don't allow RAM to be mapped - this causes problems with ARMv6+ +*/ +if (WARN_ON (pfn_valid (pfn))) +return NULL ; + type =get_mem_type (mtype);if (!type)return NULL ;
Quoted 13 lines · Russell King - ARM Linux
ARMv6 and above have a restriction whereby aliasing virtual:physical mappings must not have differing memory type and sharability attributes. Strictly, this covers the memory type (strongly ordered, device, memory), cache attributes (uncached, write combine, write through, write back read alloc, write back write alloc) and the shared bit.
However, using
ioremap()and its variants on system RAM results in mappings which differ in these attributes from the main system RAM mapping. Other architectures which similar restrictions approch this problem in the same way - they do not permit ioremap on main system RAM.
Quoted 4 lines
Make ARM behave in the same way, with a
WARN_ON()such that users can be traced and an alternative approach found.Signed-off-by Russell King <[email protected]>
BTW, why not do this for /dev/mem mappings with O_SYNC? I think I sent you a patch some time ago but I can re-post it.
Signature · 1 line
Catalin
Quoted 25 lines
-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Catalin Marinas
Sent: Friday, April 23, 2010 7:46 PM
To: Russell King - ARM Linux
Cc: linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC] Prohibitioremap()on kernel managed RAMQuoted 16 lines · Russell King - ARM Linux
ARMv6 and above have a restriction whereby aliasing virtual:physical mappings must not have differing memory type and sharability attributes. Strictly, this covers the memory type (strongly ordered, device, memory), cache attributes (uncached, write combine, write through, write back read alloc, write back write alloc) and the shared bit.
However, using
ioremap()and its variants on system RAM results in mappings which differ in these attributes from the main system RAM mapping. Other architectures which similar restrictions approch this problem in the same way - they do not permit ioremap on main system RAM.Make ARM behave in the same way, with a
WARN_ON()such that users can be traced and an alternative approach found.
Quoted 7 lines
Quoted 1 line
Signed-off-by Russell King <[email protected]>Reviewed-by Catalin Marinas <[email protected]>BTW, why not do this for
/dev/memmappings withO_SYNC? I think I sent you a patch some time ago but I can re-post it.
Above change is necessary but what an alternative approach is for this. There are many use case where ioremap* is needed.
Regards,
Santosh