Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 May 2005 16:00:55 -0600 (MDT)
From:      Warner Losh <imp@bsdimp.com>
To:        julian@elischer.org
Cc:        usbcrash@oldach.net
Subject:   Re: recent USB MFCs cause panics
Message-ID:  <20050505.160055.78800132.imp@bsdimp.com>
In-Reply-To: <427A9690.9080108@elischer.org>
References:  <427A8EF3.70003@elischer.org> <20050505.153302.71182158.imp@bsdimp.com> <427A9690.9080108@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Julian Elischer <julian@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@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.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050505.160055.78800132.imp>