| Message ID | 1390389916-8711-2-git-send-email-wangnan0@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jan 22, 2014 at 11:25:14AM +0000, Wang Nan wrote: > This patch relaxes the restriction set by commit 309caa9cc, which > prohibit ioremap() on all kernel managed pages. > > Other architectures, such as x86 and (some specific platforms of) powerpc, > allow such mapping. > > ioremap() pages is an efficient way to avoid arm's mysterious cache control. > This feature will be used for arm kexec support to ensure copied data goes into > RAM even without cache flushing, because we found that flush_cache_xxx can't > reliably flush code to memory. > > Signed-off-by: Wang Nan <wangnan0@huawei.com> > Cc: <stable@vger.kernel.org> # 3.4+ > Cc: Eric Biederman <ebiederm@xmission.com> > Cc: Russell King <rmk+kernel@arm.linux.org.uk> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Geng Hui <hui.geng@huawei.com> > --- > arch/arm/mm/ioremap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c > index f123d6e..98b1c10 100644 > --- a/arch/arm/mm/ioremap.c > +++ b/arch/arm/mm/ioremap.c > @@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn, > /* > * Don't allow RAM to be mapped - this causes problems with ARMv6+ > */ > - if (WARN_ON(pfn_valid(pfn))) > + if (WARN_ON(pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))) Since reserved pages can still be mapped, how does this avoid the cacheable alias issue fixed by 309caa9cc6ff ("ARM: Prohibit ioremap() on kernel managed RAM")? Will
On Wed, Jan 22, 2014 at 07:25:14PM +0800, Wang Nan wrote: > This patch relaxes the restriction set by commit 309caa9cc, which > prohibit ioremap() on all kernel managed pages. > > Other architectures, such as x86 and (some specific platforms of) powerpc, > allow such mapping. > > ioremap() pages is an efficient way to avoid arm's mysterious cache control. > This feature will be used for arm kexec support to ensure copied data goes into > RAM even without cache flushing, because we found that flush_cache_xxx can't > reliably flush code to memory. Yes, let's bypass the check and allow this in violation of the architecture specification by allowing mapping the same memory with different types, which leads to unpredictable behaviour. Yes, that's a very good idea, because what we want to do is far more important than following the requirements of the architecture. So... NAK. Yes, flush_cache_xxx() doesn't flush back to physical RAM, that's not what it's defined to do - it's defined that it flushes enough of the cache to ensure that page table updates are safe (such as when tearing down a page mapping.) So it's hardly surprising that doesn't work. If you want to be able to have DMA access to memory, then you need to use an API which has been designed for that purpose, and if there isn't one, then you need to discuss your requirements, rather than trying to hack around the problem. The issue here will be that the APIs we currently have for DMA become extremely expensive when you want to deal with (eg) all system RAM. Or, there's flush_cache_all() which should flush all levels of cache in the system, and thus push all data back to RAM. Now, why are you copying your patches to the stable people? That makes no sense - they haven't been reviewed and they haven't been integrated into an existing kernel. So, they don't meet the basic requirements for stable tree submission...
On 2014/1/22 19:42, Russell King - ARM Linux wrote: > On Wed, Jan 22, 2014 at 07:25:14PM +0800, Wang Nan wrote: >> This patch relaxes the restriction set by commit 309caa9cc, which >> prohibit ioremap() on all kernel managed pages. >> >> Other architectures, such as x86 and (some specific platforms of) powerpc, >> allow such mapping. >> >> ioremap() pages is an efficient way to avoid arm's mysterious cache control. >> This feature will be used for arm kexec support to ensure copied data goes into >> RAM even without cache flushing, because we found that flush_cache_xxx can't >> reliably flush code to memory. > > Yes, let's bypass the check and allow this in violation of the > architecture specification by allowing mapping the same memory with > different types, which leads to unpredictable behaviour. Yes, that's > a very good idea, because what we want to do is far more important than > following the requirements of the architecture. > > So... NAK. > > Yes, flush_cache_xxx() doesn't flush back to physical RAM, that's not > what it's defined to do - it's defined that it flushes enough of the > cache to ensure that page table updates are safe (such as when tearing > down a page mapping.) So it's hardly surprising that doesn't work. > > If you want to be able to have DMA access to memory, then you need to > use an API which has been designed for that purpose, and if there isn't > one, then you need to discuss your requirements, rather than trying to > hack around the problem. So what is correct API which is designed for this propose? > > The issue here will be that the APIs we currently have for DMA become > extremely expensive when you want to deal with (eg) all system RAM. > Or, there's flush_cache_all() which should flush all levels of cache > in the system, and thus push all data back to RAM. > > Now, why are you copying your patches to the stable people? That makes > no sense - they haven't been reviewed and they haven't been integrated > into an existing kernel. So, they don't meet the basic requirements > for stable tree submission... >
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c index f123d6e..98b1c10 100644 --- a/arch/arm/mm/ioremap.c +++ b/arch/arm/mm/ioremap.c @@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn, /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ - if (WARN_ON(pfn_valid(pfn))) + if (WARN_ON(pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))) return NULL; area = get_vm_area_caller(size, VM_IOREMAP, caller);
This patch relaxes the restriction set by commit 309caa9cc, which prohibit ioremap() on all kernel managed pages. Other architectures, such as x86 and (some specific platforms of) powerpc, allow such mapping. ioremap() pages is an efficient way to avoid arm's mysterious cache control. This feature will be used for arm kexec support to ensure copied data goes into RAM even without cache flushing, because we found that flush_cache_xxx can't reliably flush code to memory. Signed-off-by: Wang Nan <wangnan0@huawei.com> Cc: <stable@vger.kernel.org> # 3.4+ Cc: Eric Biederman <ebiederm@xmission.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Geng Hui <hui.geng@huawei.com> --- arch/arm/mm/ioremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)