From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 20:02:35 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 5805816A4D1 for ; Mon, 11 Oct 2004 20:02:35 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B1B543D2D for ; Mon, 11 Oct 2004 20:02:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26111 invoked from network); 11 Oct 2004 19:53:08 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Oct 2004 19:53:08 -0000 Message-ID: <416AE70B.3030900@freebsd.org> Date: Mon, 11 Oct 2004 22:03:23 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: <4165ADC2.70D2F0C1@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org 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: Mon, 11 Oct 2004 20:02:35 -0000 Sam wrote: >> 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. > > This bug is not fixed in 5.3-beta7 or -current. Unloading a > module that unregisters a netisr leaves the queue pointer for that > netisr structure page fault ready. You are right indeed. Sorry for the confusion. There have been other bugs fixed but not this one. I've commited your fix in rev. 1.15 of net/netisr.c. Thanks for submitting the bug report and proving me wrong ;-) -- Andre >> 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >