From owner-freebsd-current@FreeBSD.ORG Wed Mar 3 21:26:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9DD616A4CE; Wed, 3 Mar 2004 21:26:03 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3958143D1D; Wed, 3 Mar 2004 21:26:03 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i245Q1Ue008268; Thu, 4 Mar 2004 16:26:01 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i245Pw5c006143; Thu, 4 Mar 2004 16:26:00 +1100 Date: Thu, 4 Mar 2004 16:25:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20040304160921.X5609@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: sysctl spinning (was: Re: ps Causes Hard Hang) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 05:26:04 -0000 On Wed, 3 Mar 2004, Robert Watson wrote: > On Wed, 3 Mar 2004, Cy Schubert wrote: > > > I'm running 5 -CURRENT systems. My firewall system, using IPF, hard > > hangs every time ps is entered -- totally unresponsive, requiring either > > a power cycle or reset switch to bring it back to life. > > Alan Cox and I have both experienced this -- it's actually only a hard > hang if you're trying to use the syscons break to debugger, serial break > to debugger can get into DDB fine. It looks like the sysctl code is > spinning in kernel, possibly due to looping waiting for a response other > than EAGAIN. I'm wonder if it was the recent limits on locked memory > changes in sysctl, although at first we thought it might be the sleepq > changes (seems less likely now). Because sysctl holds Giant, the other > CPUs are locked out of Giant-protected bits of the kernel (many of them), > including Syscons. It also holds sysctllock, but should possibly drop both for loops like this. Such loops should be harmless on preemptible kernels. Processes doing them should be preemptible and scheduled in the usual way (and killable). However, holding Giant prevents preemption except by INTR_MPSAFE interrupt handlers (and userland CPU hogs?). I plan to fix not-so-similar loops in vn_rdwr_inchunks() (callers of) uiomove() by just dropping Giant. These loops already drop Giant in uio_yield(), but calling uio_yield() shouldn't be needed on preemptible kernels, and the calls in uiomove() no longer work properly (switchticks is reset on every context switch and context switches happen too often to pessimize interrupt handling, so switchticks can only grow to hogticks in exceptional cases). Bruce