> 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 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 >> _at__at_ -103,6 +103,7 _at__at_ >> 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 >>Received on Mon Oct 11 2004 - 17:36:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC