Re: [PATCH] Alternate futex non-page-pinning and COW fix

[Linus Torvalds]

On Wed, 3 Sep 2003, Hugh Dickins wrote:
> 
> Maybe, but, if the file was opened for writing as well as reading, the
> shared read-only mapping can be mprotected to read-write at any point,
> which does lead to differences: which is why Linux is very careful
> about deciding VM_SHARED, and it's quite difficult to explain.

And that's why the kernel does this:

	case MAP_SHARED:
		....

		vm_flags |= VM_SHARED | VM_MAYSHARE;
		if (!(file->f_mode & FMODE_WRITE))
			vm_flags &= ~(VM_MAYWRITE | VM_SHARED);
		...

ie it only degenerates the shared mapping to a private mapping if it 
_also_ removes the MAYWRITE bit.

So if the mapping is a shared mapping and read-only - but the file was 
opened read-write and the mapping may later be changed to a writable one - 
then Linux will keep the mapping VM_SHARED.

> If we document how sys_futex (which does not dirty a page, doesn't
> even need a page there) behaves when placed within different kinds
> of mmaps, it's easier for the reader to understand if we don't get
> into such sophistications - hence choice of VM_MAYSHARE equivalent
> to MAP_SHARED, never mind the readwriteness.

I'd be very very nervous about anything that documents a read-only
MAP_SHARED as anythign but a MAP_PRIVATE. That just is fundamentally not 
right, and it _will_ bite us at some point, since all of the rest of the 
VM thinks that they are the same.

		Linus

-
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/