From owner-svn-src-all@FreeBSD.ORG Sat Dec 22 09:57:10 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A73AA06; Sat, 22 Dec 2012 09:57:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC638FC12; Sat, 22 Dec 2012 09:57:09 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id z14so6457638lag.30 for ; Sat, 22 Dec 2012 01:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZZ+VoumboiwTAnguLL3nVqMKadeT2nM3kH2X5uMLsaM=; b=tZWWzsZCVlnKd8aeWM/zMAjj+32WUX4rKm2TBRZ/HB7qahVuKMy8OQxwshNVJgnxeu 3FW+K+jq8tsQzMc3MPvhFTfncsvRY0lmm5UuRsABE7qaRMDrF2SMTDeaDBjGD1hSc7tG HVqaX+QTD9m/vOU1iJZawS3MSOkC56/iy8PvBwUvgTC/5VB0MD67csxZySDfzg+zmRqF 9WUrmafFz0NfO0iU2evvdlbP+R5TLoLbSkOALpofSMlW2oUtcoWMQto4cKSUw9R+FSRB gL4bfURFaM3ieLQv3ZfxdUVWRXFmk8dlRPgFfmtZjIMd6WLRUZia8COMe2WEVzzmRCcf mmKQ== MIME-Version: 1.0 Received: by 10.112.37.200 with SMTP id a8mr6509692lbk.92.1356170227682; Sat, 22 Dec 2012 01:57:07 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.84.193 with HTTP; Sat, 22 Dec 2012 01:57:07 -0800 (PST) In-Reply-To: <20121222204409.V1410@besplex.bde.org> References: <201212220937.qBM9bYQK050680@svn.freebsd.org> <20121222204409.V1410@besplex.bde.org> Date: Sat, 22 Dec 2012 10:57:07 +0100 X-Google-Sender-Auth: EM_HwXuzvJRLPtGal7AHu_WxHCk Message-ID: Subject: Re: svn commit: r244582 - head/sys/kern From: Attilio Rao To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 09:57:10 -0000 On Sat, Dec 22, 2012 at 10:51 AM, Bruce Evans wrote: > On Sat, 22 Dec 2012, Attilio Rao wrote: > >> Log: >> Fixup r240424: On entering KDB backends, the hijacked thread to run >> interrupt context can still be idlethread. At that point, without the >> panic condition, it can still happen that idlethread then will try to >> acquire some locks to carry on some operations. >> >> Skip the idlethread check on block/sleep lock operations when KDB is >> active. > > > This seems backwards to me. It is an error to go near normal locking > code when kdb is active. I completely agree, but this is not what happens nowadays with FreeBSD kernel. In my view, KDB should not call into normal code, but in special wrappers which skip locking entirely, in particular because other cpus are stopped, so there is no race going on. However, this requires a big change and as long as this doesn't happen we need to stuck with similar hacks. > > >> Modified: head/sys/kern/kern_lock.c >> >> ============================================================================== >> --- head/sys/kern/kern_lock.c Sat Dec 22 07:48:09 2012 (r244581) >> +++ head/sys/kern/kern_lock.c Sat Dec 22 09:37:34 2012 (r244582) >> @@ -35,6 +35,7 @@ >> __FBSDID("$FreeBSD$"); >> >> #include >> +#include >> #include >> #include >> #include >> @@ -477,7 +478,7 @@ __lockmgr_args(struct lock *lk, u_int fl >> KASSERT((flags & LK_INTERLOCK) == 0 || ilk != NULL, >> ("%s: LK_INTERLOCK passed without valid interlock @ %s:%d", >> __func__, file, line)); >> - KASSERT(!TD_IS_IDLETHREAD(curthread), >> + KASSERT(kdb_active != 0 || !TD_IS_IDLETHREAD(curthread), >> ("%s: idle thread %p on lockmgr %s @ %s:%d", __func__, >> curthread, >> lk->lock_object.lo_name, file, line)); > > > This is backwards from: > > KASSERT(kdb_active == 0); > > which makes it fatal for any thread to call here. I do not understand. For kdb_active == 0 it still checks for IDLETHREAD if it is not idlethread it doesn't panic, it panics otherwise, which seems the right to me. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein