sys/net/netisr.c

[Andre Oppermann]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"