Re: sys/net/netisr.c

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
>>> _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
>>>
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 
>