From owner-freebsd-bugs@FreeBSD.ORG Sat Apr 7 03:30:11 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABD0B16A469 for ; Sat, 7 Apr 2007 03:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 066A413C480 for ; Sat, 7 Apr 2007 03:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l373UAtH050915 for ; Sat, 7 Apr 2007 03:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l373UA7E050914; Sat, 7 Apr 2007 03:30:10 GMT (envelope-from gnats) Date: Sat, 7 Apr 2007 03:30:10 GMT Message-Id: <200704070330.l373UA7E050914@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Kris Kennaway Cc: Subject: Re: kern/111260: FreeBSD kernel dead lock and a solution X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 03:30:11 -0000 The following reply was made to PR kern/111260; it has been noted by GNATS. From: Kris Kennaway To: Zhouyi Zhou Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/111260: FreeBSD kernel dead lock and a solution Date: Fri, 6 Apr 2007 23:25:04 -0400 On Thu, Apr 05, 2007 at 09:04:57AM +0000, Zhouyi Zhou wrote: > In the recently testing of FreeBSD using people.freebsd.org/~pho/stress/src/stress2.tgz, when running the 7 tests simulatanouly, the FreeBSD kernel will goto dead lock after three or more days . > > The reason is as follows: > In function vm_fault at vm/vm_fault.c > > 299 fs.vp = vnode_pager_lock(fs.first_object); > 300 KASSERT(fs.vp == NULL || !fs.map->system_map, > > The kernel will try to get a lock on fs.vp with the fs.map still locks. > > while in function do_execve at kern/kern_exec.c > > 462 if (p->p_sysent->sv_copyout_strings) > 463 stack_base = (*p->p_sysent->sv_copyout_strings)(imgp); > 464 else > 465 stack_base = exec_copyout_strings(imgp); > 466 > 467 /* > 468 * If custom stack fixup routine present for this process > 469 * let it do the stack setup. > 470 * Else stuff argument count as first item on stack > 471 */ > 472 if (p->p_sysent->sv_fixup != NULL) > 473 (*p->p_sysent->sv_fixup)(&stack_base, imgp); > 474 else > 475 suword(--stack_base, imgp->args->argc); > The copyout function may cause vm_fault on line 463 or 465, which will try to lock the kernel_map->root->object.sub_map, which is locked by another process in vm_fault above. While at mean time the imgp->vp is still got locked. Can you please provide backtraces that lead you to this conclusion? Thanks, Kris