Re: Properly implement flush_dcache_page in 2.4? (Or is it possible?)

[Russell King (rmk@arm.linux.org.uk)]

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@xxxxxxxxxxxxxxxx)                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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/