lkml.org 
[lkml]   [2003]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] Futex non-page-pinning fix
    On Tue, 2 Sep 2003, Jamie Lokier wrote:
    > What happens after this sequence:
    >
    > 1. process A forks, making process B
    > 2. B does FUTEX_FD, or splits into threads and one does FUTEX_WAIT,
    > on a private page that has not been written to since the fork
    > 3. A does FUTEX_WAIT on the same address
    > 3. The page is swapped out
    > 4. B does FUTEX_WAKE at the same address
    >
    > Won't the futex be hashed on the swap entry at step 4, so that
    > both processes are woken, yet only the waiter in B should be woken?

    I don't see that step 3 (the second!) makes any difference:
    it behaves like that whether or not the page is swapped out, doesn't it?

    I agree with you that behaviour seems wrong for a private anonymous page.
    And we'd agree it's right behaviour for a shared file page. The case of
    a MAP_PRIVATE or !PROT_WRITE file page may be harder to decide, but I'm
    inclined to follow you and say distinction should depend on MAP_SHARED
    (shm included as MAP_SHARED mapping of unnamed shmem object).

    I know nothing of the user/glibc end of futexes, perhaps it makes
    your case academic. But I'd still like a consistent definition
    for how sys_futex should behave.

    I'd been wondering along similar lines (worried by futex on uninstantiated
    anon page, which would end up on the empty zero page), thinking futex.c's
    __pin_page ought to pass write flag set to follow_page and get_user_pages.

    But now (and I'd like to switch to capitals, but restrain myself) I think
    most of the COW/vcache/callback/swap/page/pinning stuff is just a waste
    of space and time, creating its own problems which it then has to solve.

    When sys_futex passes a uaddr in a VM_MAYSHARE vma, it should be handled
    by mapping/index (or inode/offset). When sys_futex passes a uaddr in a
    !VM_MAYSHARE vma, it should be handled by mm/uaddr. (If outside vma?)

    That's it. Doesn't a whole lot of code and complication fall away?
    The physical page is pretty much irrelevant.

    For a while I thought this would change the behaviour if futex is
    mremapped. Well, yes, but nobody has remembered to do anything
    about vcache in mremap anyway, so it's already broken.

    What am I missing?

    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/
    On Tue, 2 Sep 2003, Jamie Lokier wrote:
    > What happens after this sequence:
    >
    > 1. process A forks, making process B
    > 2. B does FUTEX_FD, or splits into threads and one does FUTEX_WAIT,
    > on a private page that has not been written to since the fork
    > 3. A does FUTEX_WAIT on the same address
    > 3. The page is swapped out
    > 4. B does FUTEX_WAKE at the same address
    >
    > Won't the futex be hashed on the swap entry at step 4, so that
    > both processes are woken, yet only the waiter in B should be woken?

    I don't see that step 3 (the second!) makes any difference:
    it behaves like that whether or not the page is swapped out, doesn't it?

    I agree with you that behaviour seems wrong for a private anonymous page.
    And we'd agree it's right behaviour for a shared file page. The case of
    a MAP_PRIVATE or !PROT_WRITE file page may be harder to decide, but I'm
    inclined to follow you and say distinction should depend on MAP_SHARED
    (shm included as MAP_SHARED mapping of unnamed shmem object).

    I know nothing of the user/glibc end of futexes, perhaps it makes
    your case academic. But I'd still like a consistent definition
    for how sys_futex should behave.

    I'd been wondering along similar lines (worried by futex on uninstantiated
    anon page, which would end up on the empty zero page), thinking futex.c's
    __pin_page ought to pass write flag set to follow_page and get_user_pages.

    But now (and I'd like to switch to capitals, but restrain myself) I think
    most of the COW/vcache/callback/swap/page/pinning stuff is just a waste
    of space and time, creating its own problems which it then has to solve.

    When sys_futex passes a uaddr in a VM_MAYSHARE vma, it should be handled
    by mapping/index (or inode/offset). When sys_futex passes a uaddr in a
    !VM_MAYSHARE vma, it should be handled by mm/uaddr. (If outside vma?)

    That's it. Doesn't a whole lot of code and complication fall away?
    The physical page is pretty much irrelevant.

    For a while I thought this would change the behaviour if futex is
    mremapped. Well, yes, but nobody has remembered to do anything
    about vcache in mremap anyway, so it's already broken.

    What am I missing?

    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.030 / U:0.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site