Re: [PATCH] Alternate futex non-page-pinning and COW fix
From: Linus Torvalds
Date: Wed Sep 03 2003 - 13:32:37 EST
On Wed, 3 Sep 2003, Hugh Dickins wrote:
> >
> > The VM itself should only ever care about VM_SHARED. Because that's the
> > only bit that has real semantic meaning.
>
> To that part of the kernel interested in dirty pages, yes.
> But when interested in futexes, it seems not.
I don't like it.
If the patches can't be made to work for private mappings, then there's
something fundamentally wrong with them.
A non-writable shared mapping has degenerated into a private mapping since
the very first releases of Linux that supported mmap. It started out as a
"hey, we don't support true writable shared mappings, but we _do_ support
cache coherency on read-only mmaps through the normal private mappings,
so..".
And even later on, when true shared mappings were supported, we continued
the "degenerate to a private mapping" approach because the private
mappings tend to be simpler and require less overhead (exactly because
they don't need to worry about dirty bits).
So part of the picture is that this is just how the Linux VM fundamentally
works.
The other part of the picture is that futex'es should "just work" even
when it comes to regular private mappings. Regardless of any VM_SHARED or
VM_MAYSHARE bits. Even if the user did a totally private mmap() in the
first place, that does not mean that the futex shouldn't work properly.
So the thing boils down to:
- if the futex works on a proper private mapping, then the downgrade is
still proper, and the futex should never care about anything but a real
VM_SHARED.
- if the futex doesn't work with a proper private mapping, then that is a
bug _regardless_ of anything else, and VM_SHARED vs VM_MAYSHARE never
enters into the picture anyway.
What?
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/