On Wed, Nov 19, 2008 at 05:40:23PM +1100, Nick Piggin wrote: > It would be interesting to know exactly what problem you are seeing. > > ARM I think is supposed to handle aliasing problems by flushing > caches at appropriate points. It would be nice to know what's going > wrong and whether we can cover those holes. I think there's a problem here: the existing cache handling API is designed around the MM's manipulation of page tables. It is generally not designed to handle aliasing between multiple mappings of the same page, except with one exception: page cache pages mmap'd into userspace, which is handled via flush_dcache_page(). O_DIRECT on ARM is probably completely untested for the most part. It's not something that is encountered very often, and as such gets zero testing. I've certainly never had the tools to be able to test it out, so even on VIVT it's probably completely buggy. Bear in mind that most of my modern platforms use MTD (either cramfs or in the rare case jffs2) so I'm not sure that I could sensibly even test O_DIRECT - isn't O_DIRECT for use with proper block devices? As it's probably clear, I've no clue of the O_DIRECT implementation or how it's supposed to work. At a guess, it probably needs a new cache handling API to be designed, since the existing flush_cache_(range|page) are basically no-ops on VIPT. Or maybe we need some way to mark the userspace pages as being write-through or uncacheable depending on the features we have available on the processor. Or something. Don't know. So, what is O_DIRECT, and where can I find some information about it? I don't see anything in Documentation/ describing it. -- 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
