Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753934AbZG2K43 (ORCPT ); Wed, 29 Jul 2009 06:56:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751123AbZG2K42 (ORCPT ); Wed, 29 Jul 2009 06:56:28 -0400 Received: from gw1.cosmosbay.com ([212.99.114.194]:37453 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750780AbZG2K42 (ORCPT ); Wed, 29 Jul 2009 06:56:28 -0400 Message-ID: <4A702AC2.2060003@gmail.com> Date: Wed, 29 Jul 2009 12:56:02 +0200 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jens Rosenboom CC: Peter Zijlstra , Sonny Rao , Linux Kernel Mailing List , Ingo Molnar , Thomas Gleixner Subject: Re: futexes: Still infinite loop in get_futex_key() in 2.6.31-rc4 References: <1248681637.7279.12.camel@fnki-nb00130> <1248694266.6987.1594.camel@twins> <1248697004.7279.31.camel@fnki-nb00130> <1248697409.6987.1617.camel@twins> <1248698755.7279.47.camel@fnki-nb00130> <1248701812.6987.1637.camel@twins> <1248848568.6757.13.camel@fnki-nb00130> <1248861443.6757.20.camel@fnki-nb00130> <4A7023BC.6000109@cosmosbay.com> In-Reply-To: <4A7023BC.6000109@cosmosbay.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Wed, 29 Jul 2009 12:56:02 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2730 Lines: 75 Eric Dumazet a ?crit : > Jens Rosenboom a ?crit : >> On Wed, 2009-07-29 at 08:22 +0200, Jens Rosenboom wrote: >>> On Mon, 2009-07-27 at 15:36 +0200, Peter Zijlstra wrote: >>> [...] >>>> Bugger.. how easy it is to reproduce? >>> Okay, my colleague found the right combination of scripts, take the two >>> attached, run them both a couple of times in parallel for some hours, >>> and get a stuck ps. This happens both on an old 2.6.29.1 I happened to >>> still have on one machine as with 2.6.31-rc4. Both of them dual-core >>> Opterons as the original one. If you want further tracebacks or other >>> information, let me know. >> Forget about null.pl even, just run pees.pl twice and a top to watch it, >> has worked for me within less than an hour several times now. >> > > Ah that makes sense now... > > maybe execve() forgets to clear clear_child_tid > Sorry , I hit 'Send' before completing the mail... Could you please try following patch ? [PATCH] exec: must clear clear_child_tid "ps", while reading /proc/xxx files, has to raise mm_users count (via a call to get_task_mm()) So when the exiting process (and spied by a ps) calls mm_release() we could go through : if (tsk->clear_child_tid && !(tsk->flags & PF_SIGNALED) && atomic_read(&mm->mm_users) > 1) { u32 __user * tidptr = tsk->clear_child_tid; tsk->clear_child_tid = NULL; /* * We don't check the error code - if userspace has * not set up a proper pointer then tough luck. */ put_user(0, tidptr); sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0); } It can happen if execve() doesnt set clear_child_tid to NULL, and we try to futex() to a tidptr that has no meaning (it had a meaning only in bash space, before its thread did the execve()) Furthermore, we can call put_user(0, tidptr), overwriting some integer in our user space and corrupt user memory. (if the initial thread exits) Reported-by: Jens Rosenboom Signed-off-by: Eric Dumazet --- diff --git a/fs/exec.c b/fs/exec.c index 4a8849e..e275652 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1343,6 +1343,7 @@ int do_execve(char * filename, mutex_unlock(¤t->cred_guard_mutex); acct_update_integrals(current); free_bprm(bprm); + current->clear_child_tid = NULL; if (displaced) put_files_struct(displaced); return retval; -- 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/