Date: Thu, 4 Sep 2003 08:40:14 -0700 (PDT)
From: Linus Torvalds <torvalds@osdl.org>
To: Hugh Dickins <hugh@veritas.com>
cc: Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
       Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@redhat.com>,
       <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Alternate futex non-page-pinning and COW fix
In-Reply-To: <Pine.LNX.4.44.0309041230020.3647-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0309040837560.580-100000@home.osdl.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1312
Lines: 32


On Thu, 4 Sep 2003, Hugh Dickins wrote:
> 
> Isn't it the case that to use sys_futex (in the way it's intended),
> userspace needs write access to the futex?  FUTEX_WAIT and FUTEX_WAKE
> are used (depending on condition) after decrementing or incrementing
> the futex in userspace.  FUTEX_FD is not such a clear case, but again
> it appears that you'd use it for an async wait after decrementing.
> FUTEX_REQUEUE seems to be a move or remap, doesn't change the picture.

Yes. 

We can certainly just document it as a nonsense op. All I care about is
that it is _consistently_ broken, and that people don't make read-only
MAP_SHARED do something it has never ever done before - differ from a
semantic standpoint.

> The particular case above: if it's !PROT_WRITE MAP_PRIVATE, I'm
> saying that's not an area you can manipulate mutexes in anyway;

However, the thing is, the case really can be a totally writable
MAP_PRIVATE that just hasn't been modified (and thus not COW'ed) _yet_.

But sure, we could just require that futex pages are dirty in this case.

		Linus

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