[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
Peter Zijlstra wrote:
> 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

Yup, that's the one. I was trying to locate it myself, but you beat me
to it. Thanks Peter.

Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
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:23    [W:0.073 / U:0.164 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site