On Wed, 2016-04-13 at 23:16 +0200, Luis R. Rodriguez wrote: > On Thu, Mar 17, 2016 at 04:44:53PM -0600, Toshi Kani wrote: > > On Wed, 2016-03-16 at 02:45 +0100, Luis R. Rodriguez wrote: > > > On Fri, Mar 11, 2016 at 03:13:52PM -0700, Toshi Kani wrote: : > > > > > > If aliasing with different cache attributes is not allowed for x86 > > > and if its also rare for other architectures that just leaves the > > > hunt for valid aliasing uses. That still may be hard to hunt for, but > > > I also suspect it may be rare. > > > > Yes, I'd fail the different cache attribute case if we are to place > > more strict check. > > OK it seems this is a good starting point. How can we get a general > architecture consensus aliasing with different cache attributes is a > terrible idea ? Perhaps a patch to WARN/error out and let architectures > opt in to this piece of code? I expect aliasing with different cache attributes is a bad idea on most architectures. Given the fact that track_pfn_remap(), track_pfn_insert(), etc. are only implemented on x86, I suspect that other architectures would not be able to implement such check easily, though. On x86, ioremap() and remap_pfn_range() already fail on a conflicting cache type if it is not allowed by the rule defined in is_new_memtype_allowed(). This exception handling is necessary for remap_pfn_range() called by /dev/mem, but I do not think it's necessary for ioremap(). I think we can start from adding a warning message to ioremap(). > > > > > Are there cases where we change the caching attribute of RAM for > > > > > valid reasons, outside of legacy quirks? > > > > > > > > ati_create_page_map() is one example that it gets a RAM page > > > > by __get_free_page(), and changes it to UC by calling set_memory_uc > > > > (). > > > > > > Should we instead have an API that lets it ask for RAM and of UC > > > type? That would seem a bit cleaner. BTW do you happen to know *why* > > > it needs UC RAM types? > > > > This RAM page is then shared between graphic card and CPU. I think > > this is because graphic card cannot snoop the cache. > > Was this reason alone sufficient to open such APIs broadly for RAM? According to commit 75cbade8ea3, such APIs were introduced because drivers previously had to deal with low-level staff. So, I think we need to keep them as long as we have such drivers... Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
