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

[Jamie Lokier]

Hugh Dickins wrote:
> > Good question.  No kernel code seems to check VM_MAYSHARE - the one to
> > check is VM_SHARED.
> 
> Observe fs/procfs/task_mmu.c show_map checking VM_MAYSHARE for 's'.
> Observe mm/mmap.c do_mmap_pgoff vm_flags &= ~(VM_MAYWRITE | VM_SHARED).
> VM_MAYSHARE reflects whether user chose MAP_SHARED, VM_SHARED may not.

Hugh, thank you.  In the case of futex.c, either flag could be used to
mean "is this a shared" mapping, and each choice has a different
user-visible meaning.

Most of the VM code uses VM_SHARED to ask the question "is this a
shared mapping", but it turns out that most of the VM code means
something different by that than what is meant in userspace.  To the
VM code, a "shared mapping" means something which can dirty
backing-file pages, either after mmap() or maybe mprotect() as well.

This is different to the userspace point of view.  The common language
is unfortunate.  (IMHO the flag should be called VM_SHAREDWRITABLE).

With futex.c using VM_SHARED to determine whether to hash on
(inode,offset,index), mappings of read-only file handles will hash on
(mm,uaddr) which is not correct: a FUTEX_WAIT on a shared mapping
using userspace's meaning of "shared mapping" should notice changes in
a different mm.

Therefore, futex.c will use VM_MAYSHARE in my next patch.

Thanks,
-- Jamie
-
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/