From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 30 05:48:09 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF48E16A4CE; Wed, 30 Mar 2005 05:48:09 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC8743D48; Wed, 30 Mar 2005 05:48:09 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j2U5m6Hn015373; Wed, 30 Mar 2005 15:48:06 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j2U5m2Mq015626; Wed, 30 Mar 2005 15:48:05 +1000 Date: Wed, 30 Mar 2005 15:48:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Oleg Tarasov In-Reply-To: <83927877.20050329121520@osk.com.ua> Message-ID: <20050330150538.A16886@delplex.bde.org> References: <815955888.20050323113529@osk.com.ua> <20050323235823.E19701@epsplex.bde.org> <83927877.20050329121520@osk.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-bugs@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re: sio interrupt-level buffer overflows X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 05:48:09 -0000 On Tue, 29 Mar 2005, Oleg Tarasov wrote: > Bruce Evans wrote: > >> I can't explain the panic. The only relevant difference that I can think >> of is that the change gives larger interrupt-level buffers in sio. ppp >> might be depending on them not being very large. However, at the interrupt >> level, ppp just copies data 1 character at a time into mbufs, so there is >> not much to go wrong. Does the panic occur in ppp (in the kernel) or in sio? > > This problem had unusual solution. It seems the key to this problem is > that FreeBSD 5.3-STABLE-p5 (I have updated my system) has DEADLOCKS > when intensively using sio device on high speed (115200) with SMP support. > It seems that MPSAFE causes those deadlocks. Turning > > debug.mpsafenet="0" > > in /boot/loader.conf > makes the system to work fine & stable instead of panicing every hour > or more often The upper layers of sio are not MPSAFE (and the lowest layer of interrupt handling doesn't claim to be MPSAFE although it is, but that is not the problem here -- it just a pessimization). I think this prevents ppp working with debug.mpsafe != 0. I don't know if debug.mpsafe != 0 works with !MPSAFE hardware network drivers, but ppp is mostly in software so it is more likely to have problems. ppp used to be locked by splnet(), spltty() and splimp(), with spltty() stronger than splnet() and splimp() stronger than splimp(). Now these functions are null, and things only work if everything is Giant-locked. Things are mostly Giant-locked, but netisrs aren't when debug.mpsafenet != 0, so there is a priority inversion: netisrs can interrupt lower level i/o code that uses splimp() to attempt to lock out netisrs. ppp is missing a NET_NEEDS_GIANT() declaration that would automatically turn off debug.mpsafe (for the whole system :-() when ppp is configured, even if ppp is never used (:-() or if it is used with a driver that is MPSAFE. However, no serial drivers are fully MPSAFE (since upper tty layers aren't MPSAFE), so there may be no serial drivers that are MPSAFE enough to support ppp, and ppp itself might not be MPSAFE. This problem probably affects slip too. Bruce