From owner-freebsd-current Wed Aug 23 22:49: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 534FA37B422; Wed, 23 Aug 2000 22:49:05 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7O5n5p00891; Wed, 23 Aug 2000 22:49:05 -0700 (PDT) Date: Wed, 23 Aug 2000 22:49:05 -0700 From: Alfred Perlstein To: Brian Fundakowski Feldman Cc: John Polstra , current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823224905.W4854@fw.wintelcom.net> References: <20000823145244.J4854@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from green@FreeBSD.ORG on Thu, Aug 24, 2000 at 01:05:13AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brian Fundakowski Feldman [000823 22:05] wrote: > On Wed, 23 Aug 2000, Alfred Perlstein wrote: > > > * Alfred Perlstein [000823 14:29] wrote: > > > > > > I have a feeling that this is related to missing spl protection around > > > the chgsbsize subsystem, this was probably an issue before I touched it > > > but since I touched it last I'll have a look-see. > > > > > > Brian, does that makes sense? > > [...] > > > > Does it make sense to wrap chgsbsize with spl so callers don't have > > to worry about it? > > > > Yeah, I say to go for it. I was /certain/ that these functions had > the right spl()s before; if the patch fixes jdp's problem, I can't see > a good reason not to change it, other than it would hide what may be > quite problematic for other reasons even if not for that one... Actually with my patches he still has problems, but I just realized that I'm using splnet in my patches, should I be using splimp? patch is here: http://people.freebsd.org/~alfred/sbsize_spl.diff Note that I'm quite sure it's not just sbsize which needs spl, it's the code that modifies the socketbuffer's size fields as well as the chgsbsize() calls otherwise user context may be preempted by a packet closing the connection after sbsize has been adjusted but not before the buffer sizes have been fixed in the socket struture causing the interrupt context to try to chgsbsize again. Or at least that's what I think may be going on. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message