Messages in this thread | | | Date | Sat, 31 May 2003 10:19:32 +0100 | From | Russell King <> | Subject | Re: Properly implement flush_dcache_page in 2.4? (Or is it possible?) |
| |
On Sat, May 31, 2003 at 09:33:04AM +0100, Hugh Dickins wrote: > I was about to concede to you: just because the pages are shared doesn't > mean that _you_ have to be overanxious about immediately forcing changes > to be visible to userspace (though it would be unfriendly if updates were > to appear at lesser granularity than PAGE_SIZE: I've no idea whether > that's a possibility), the "unspecified" would allow that much - but > wouldn't allow you to show portions of entirely other files!
Other files should not be stored in the same page though - if that's happening today, then we have a violation of POSIX, wrong from Linus' "quality of implementation" standpoint, and its a security hole.
> But I've just remembered the peculiar VM_SHARED handling in mm/mmap.c: > open a file O_RDONLY, mmap it PROT_READ MAP_SHARED, and the vma will be > put on the i_mmap list, not on the i_mmap_shared list. So the i_mmap > list can actually contain shared mappings, not just private mappings. > Poor naming certainly: the i_mmap_shared list is for mappings though > which the object might be modified.
Hmm, you're right here. I wonder whether we could allow VM_SHARED to be set on such mappings, thereby putting the pages on the i_mmap_shared list rather than the i_mmap list.
The alternative is that we scan these two lists for every case which we need to do something; this seems to make the split lists rather pointless from an architecture implementors point of view.
Maybe some of the VM gurus can shed some more light on this subject?
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
- 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/
| |