On Thu, 2011-12-01 at 05:54 +0800, Luck, Tony wrote:
> > But as this code may be used in general acpi_read/write path too in the
> > future, can you verify whether it is harmless on ia64?
>
> This might be a problem on ia64 - it is s/w responsibility to make sure
> that we don't map the same underlying physical address using different
> cache attributes - e.g. we must not map memory both cacheable and uncacheable
> at the same time. Accessing such a mis-attributed page will result in a
> machine check.
>
> So I'd worry that if the memory in question was being used as uncacheable,
> this code might result in a cached access, which would crash the machine.
+static void __iomem *acpi_map(phys_addr_t pg_off, unsigned long pg_sz)
+{
+ unsigned long pfn;
+
+ pfn = pg_off >> PAGE_SHIFT;
+ if (page_is_ram(pfn)) {
+ if (pg_sz > PAGE_SIZE)
+ return NULL;
+ return (void __iomem __force *)kmap(pfn_to_page(pfn));
+ } else
+ return ioremap(pg_off, pg_sz);
+}
Is it possible to use the page_is_ram() and kamp() path in the patch to avoid the situation you mentioned?
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
