lkml.org 
[lkml]   [2003]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Alternate futex non-page-pinning and COW fix
On Thu, 4 Sep 2003, Linus Torvalds wrote:
> On Thu, 4 Sep 2003, Rusty Russell wrote:
> >
> > However, Jamie's futex code will see !VM_SHARED on the mapping, and
> > compare futexes by mm + uaddr (rather than inode + file offset), so
> > this is NOT the case. Using VM_MAYSHARE instead would make the
> > MAP_SHARED readonly case work as above, though.
>
> But that is WORSE!
>
> Now MAP_SHARED works, but MAP_PRIVATE does not. That's still the same bug,
> but now it' san inconsistent bug!
>
> I'd rather have a consistent bug than one that makes no sense.

Aren't we arguing back and forth about a totally pointless case?

I've at last read the futex manpages and looked at Rusty's futex-2.2,
to repair my understanding of the userspace end.

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.

So, isn't discussing sys_futex behaviour on a readonly mapping just
academic? I'd like us to define that behaviour precisely by returning
-EACCES if sys_futex is attempted on a !VM_WRITE mapping, but it's
not worth arguing over. And it doesn't matter whether Jamie tests
VM_MAYSHARE (as I argued) or VM_SHARED (as you insist): they're
set or clear together on all the writable mappings.

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;
if it's PROT_WRITE MAP_PRIVATE but the page readonly while shared
with parent, child or sibling, the prior decrement or increment
on the futex in userspace will break COW, so it's private to the
mm by the time sys_futex WAIT or WAKE is called, in either the
old or the new implementation.

(But you can construct fork-with-futex examples in which the old
implementation would share private futex between parent and child,
because no write after fork to break the COW.)

Hugh

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

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.111 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site