[lkml]   [2009]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Bug: fio traps into kernel without exiting because futex has a deadloop
    On Thu, 2009-06-11 at 07:55 +0200, Peter Zijlstra wrote:
    > On Thu, 2009-06-11 at 11:08 +0800, Zhang, Yanmin wrote:
    > > I investigate a fio hang issue. When I run fio multi-process
    > > testing on many disks, fio traps into kernel and doesn't exit
    > > (mostly hit once after runing sub test cases for hundreds of times).
    > >
    > > Oprofile data shows kernel consumes time with some futex functions.
    > > Command kill couldn't kill the process and machine reboot also hangs.
    > >
    > > Eventually, I locate the root cause as a bug of futex. Kernel enters
    > > a deadloop between 'retry' and 'goto retry' in function futex_wake_op.
    > > By unknown reason (might be an issue of fio or glibc), parameter uaddr2
    > > points to an area which is READONLY. So futex_atomic_op_inuser returns
    > > -EFAULT when trying to changing the data at uaddr2, but later get_user
    > > still succeeds becasue the area is READONLY. Then go back to retry.
    > >
    > > I create a simple test case to trigger it, which just shmat an READONLY
    > > area for address uaddr2.
    > >
    > > It could be used as a DOS attack.

    /me has morning juice and notices he sent the wrong commit...

    commit 64d1304a64477629cb16b75491a77bafe6f86963
    Author: Thomas Gleixner <>
    Date: Mon May 18 21:20:10 2009 +0200

    futex: setup writeable mapping for futex ops which modify user space data

    The futex code installs a read only mapping via get_user_pages_fast()
    even if the futex op function has to modify user space data. The
    eventual fault was fixed up by futex_handle_fault() which walked the
    VMA with mmap_sem held.

    After the cleanup patches which removed the mmap_sem dependency of the
    futex code commit 4dc5b7a36a49eff97050894cf1b3a9a02523717 (futex:
    clean up fault logic) removed the private VMA walk logic from the
    futex code. This change results in a stale RO mapping which is not
    fixed up.

    Instead of reintroducing the previous fault logic we set up the
    mapping in get_user_pages_fast() read/write for all operations which
    modify user space data. Also handle private futexes in the same way
    and make the current unconditional access_ok(VERIFY_WRITE) depend on
    the futex op.

    Reported-by: Andreas Schwab <>
    Signed-off-by: Thomas Gleixner <>

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-06-11 08:21    [W:0.023 / U:0.332 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site