From owner-freebsd-arch@FreeBSD.ORG Thu Oct 7 20:57:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAF7A16A4CE for ; Thu, 7 Oct 2004 20:57:40 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0029243D2F for ; Thu, 7 Oct 2004 20:57:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 97057 invoked from network); 7 Oct 2004 20:48:56 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Oct 2004 20:48:56 -0000 Message-ID: <4165ADC2.70D2F0C1@freebsd.org> Date: Thu, 07 Oct 2004 22:57:38 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: sys/net/netisr.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 20:57:40 -0000 Sam wrote: > > Hello - > > I think I've found a bug in -- and have a question about > the overall stability of -- sys/net/netisr.c (5.2.1 branch). This particular bug has already been fixed in 5.3 and 6.0-current. You should do your development on either RELENG_5 or MAIN. The 5.2.1 branch was only a technology demo and the areas you are concerned with have changed significantly (read: really a lot). RELENG_5 (5.3) will be the next stable branch which features future binary compatibility within further > 5.x releases. -- Andre > My AoE module calls netisr_register on load, netisr_unregister > on unload. Netisr_unregister fails to clear the ni->ni_queue > pointer and the next received frame gets queued up to a page > fault. Pretty easy to fix: > > --- src/sys/net/netisr.c Sat Nov 8 17:28:39 2003 > +++ src2/sys/net/netisr.c Thu Oct 7 15:03:39 2004 > @@ -103,6 +103,7 @@ > ni->ni_handler = NULL; > if (ni->ni_queue != NULL) > IF_DRAIN(ni->ni_queue); > + ni->ni_queue = NULL; > } > > struct isrstat { > > Looking at the code, though, I don't see why I can't > cause something just as ugly to happen anyway. Suppose > the following: cpu0 starts processing an inbound frame > while cpu1 unloads module (calling netisr_unregister). > It *seems* possible for cpu0 to get a pointer to the > queue, then cpu1 unload the module completely, causing > cpu0 to page fault on the queue address. > > I don't claim to understand the context in which > netisr_dispatch is called, so perhaps I'm off base, > but shouldn't there be a mutex protecting against this? > > Please prove me wrong. > > Sam > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"