Re: [PATCH 2] Little fixes to previous futex patch

[Jamie Lokier <jamie@shareable.org>]

Hugh Dickins wrote:
> > I don't see why you can't clear the flag: the call to ->populate will
> > change every page and pte_file to correspond with the linear page
> > offsets, which is all that !VM_NONLINEAR indicates.
> 
> You're assuming that one call to sys_remap_file_pages precisely populates
> a whole vma: no, it's quite likely it'll just do a single page of the vma.

What are you talking about?  The condition for clearing VM_NONLINEAR
is an explicit check to see if the range to be populated covers the
whole vma.

> > The important things are that the futex is queued prior to checking
> > curval, the requested page won't change (it's protected by mmap_sem),
> > and any parallel waker changes the word prior to waking us.
> 
> Ah, that may well be so, it's beyond me,
> just so long as Rusty is happy with it.

If that condition isn't enough, then async futexes are in trouble,
because the curval check equivalent is done in userspace for async
futexes...

> (I don't think you mean "the requested page won't change" - the
> down_read on mmap_sem does not prevent it from being swapped out
> before the get_user, but nor does it prevent a replacement page
> being faulted back in by get_user, and we no longer have any
> dependence on those being the same physical page.)

I mean it prevents the futex key corresponding to the userspace word
from changing before we read the word.  For all reasonable uses this
doesn't matter anyway.

-- Jamie