recent USB MFCs cause panics

[Julian Elischer]

Warner Losh wrote:

>From: Julian Elischer <julian at elischer.org>
>Subject: Re: recent USB MFCs cause panics
>Date: Thu, 05 May 2005 14:56:32 -0700
>
>  
>
>>Warner Losh wrote:
>>
>>    
>>
>>>From: Julian Elischer <julian at elischer.org>
>>>Subject: Re: recent USB MFCs cause panics
>>>Date: Thu, 05 May 2005 14:24:03 -0700
>>>
>>> 
>>>
>>>      
>>>
>>>>Julian Elischer wrote:
>>>>
>>>>try:
>>>>
>>>>in usb_port.h
>>>>comment out line 425 (as below)
>>>>
>>>>422
>>>>   423 #define config_detach(dev, flag) \
>>>>   424         do { \
>>>>   425                 /* device_detach(dev); */ \
>>>>   426                 free(device_get_ivars(dev), M_USB); \
>>>>   427                 device_delete_child(device_get_parent(dev), dev); \
>>>>   428         } while (0);
>>>>   429
>>>>   
>>>>
>>>>        
>>>>
>>>Commenting it out is lame...  I fixed this in current in uhub.c as
>>>well as here...  Since 'dev' is 0 here, I'm unsure that commenting it
>>>out will fix the problem because the next line frees it....
>>> 
>>>
>>>      
>>>
>>yes I noticed that..
>>the next line doesn't free it, it frees the ivars
>>which I don't think is the same thing..
>>    
>>
>
>if dev is NULL, then freeing the ivars from dev will still result in a
>NULL pointer dereference...
>
>  
>
>>the problem is that the 5.0 code does the  device_delete_child() (as you 
>>see above)
>>where 4.x did it in the device_detach()
>>so with this merge I get the worst of both worlds..
>>
>>the answer is to make uhub.c not call it's bus_child_detached() method 
>>(as 5.0 doesn't)
>>or to make it a null function, as it clears the subdev entry which 
>>causes this problem.
>>    
>>
>
>Yes.  I think that's the more correct fix.
>  
>

Is there a reason tio not just remove the method entry?
will it default to a good default?   (i.e. not an error default?)
if not then I guess just stubbibg the method would work..

>Warner
>  
>