I agree that it is a good thing to solve the aliasing problem, so we don't fight..
There are three cases we need to worry about physical addresses. 1) Physical addresses that we use as RAM that have a struct page. 2) Physical addresses without a struct page we map into kernel space. 3) Physical addresses without a struct page we map into user space. There are two perspectives for solving this. - phys_mem_access_prot/ia64_mem_attribute style. Where we know at bootup what access attributes everything should have, and on every mmap simply force the attribute to the correct thing. - We concede that we only know about ram with a struct page, and we let drivers do whatever they want so long as they don't use aliases. Letting drivers/users decide is the interface we have now so unless we wish to change the linux driver model we need to support it. >From this perspective I think the change should be quite simple. We need a function: verify_pfn_mapping(unsigned long pfn, unsigned long size, pgprot_t prot); That performs the following checks, on every page: - Is the page RAM with a struct page. If so it must be mapped write back. If we want anything else fail. - If the pfn is not RAM and already mapped and do the caching attributes in pgprot_t match. If we want anything else fail. - If the pfn is not mapped, allow anything that is possible. In addition we need a clean way of saying I don't care just give me a mapping with the caching attributes that are already being used, and if it is not in use give me a reasonable default. Which is what ioremap seems to do today. For the case where the physical address has a struct page we just need to detect that. For the case where we are dealing with physical addresses without a struct page we need a space efficient way to get this information. For each user mapping we already have a vm_area_struct so it makes sense to keep all of them on a linked list so we can walk through them and find any user space mappings for a pfn. For the kernel mapping with ioremap we need an architecture specific implementation because the mappings are handled in an architecture specific way. Perversely mapping physical pages with ioremap or io_remap_pfn_range may be the one case where huge pages are easy to allocate. I believe this is the primary reason why sparc64 does not use remap_pfn_range in implementing io_remap_pfn_range. So it may be worth looking at using huge mappings remap_pfn_range as part of implementing alias checking for all architectures. Unless I am hugely mistake every architecture that can set caching attributes on the page tables needs this. I am going to sleep now and work on implementing this in the morning. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/