Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761539AbZFKJgg (ORCPT ); Thu, 11 Jun 2009 05:36:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759079AbZFKJg2 (ORCPT ); Thu, 11 Jun 2009 05:36:28 -0400 Received: from casper.infradead.org ([85.118.1.10]:44694 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756630AbZFKJg2 (ORCPT ); Thu, 11 Jun 2009 05:36:28 -0400 Subject: Re: Bug: fio traps into kernel without exiting because futex has a deadloop From: Peter Zijlstra To: "Zhang, Yanmin" Cc: Darren Hart , Rusty Russell , LKML , Thomas Gleixner In-Reply-To: <1244709196.2560.287.camel@ymzhang> References: <1244689688.2560.268.camel@ymzhang> <1244699756.6691.4.camel@laptop> <1244701128.6691.5.camel@laptop> <1244709196.2560.287.camel@ymzhang> Content-Type: text/plain; charset="UTF-8" Date: Thu, 11 Jun 2009 11:36:20 +0200 Message-Id: <1244712980.6691.84.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2173 Lines: 43 On Thu, 2009-06-11 at 16:33 +0800, Zhang, Yanmin wrote: > On Thu, 2009-06-11 at 08:18 +0200, 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 > 2.6.30 includes the new commit. I did a quick testing with my simple > test case and it traps into kernel without exiting. > > The reason is I use flag FUTEX_PRIVATE_FLAG. So the fshared part in function > get_futex_key should be deleted. That might hurt performance. No reason to, the easiest fix would be to simply propagate that -EFAULT to userspace and let them chew on it, there's really nothing you can do with a RO mapping. -- 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/