Messages in this thread | | | Date | Fri, 30 May 2003 17:18:53 -0700 | From | Jun Sun <> | Subject | Re: Properly implement flush_dcache_page in 2.4? (Or is it possible?) |
| |
On Sat, May 31, 2003 at 12:14:58AM +0100, Russell King wrote: > > In addition, I am not sure if the vma struct will show up in the > > "shared" list _if_ the page is only mapped in one user process and > > in kernel (for example, those pages you obtain through get_user_pages() > > call). > > If a mapping is using MAP_SHARED, my understanding is that the pages should > appear on the i_mmap_shared list. >
That is my understanding too.
> I don't see a reason to worry about privately mapped pages on the i_mmap > list since they are private, and therefore shouldn't be updated with > modifications to other mappings,
Actually there is, at least in 2.4. Whenever kernel calls get_user_pages() it maps a user page into kernel virtual address space. If kernel modifies that page, flush_dcache_page() needs to make sure any stale cache data at user virtual address is flush in order user to see kernel changes.
I have a test case at
http://linux.junsun.net/test-programs
(Note, sometimes even if you pass the test, you _may_ still have a wrong flush_dcache_page() implementation, because stale cache could be flushed due to other execution sequences)
I took a brief look of 2.5 code. It seems this problem should still exist (of course, assuming the CPU has cache aliasing problem and the flush_dcache_page() is not properly implemented).
Actually in 2.5 you may fail the test even if you have a properly implemented flush_dcache_page(). It appears it lacks another flush_dcache_page() after the direct_IO is done. I don't have a working 2.5 on MIPS. Can't verify that.
Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |