Date: Tue, 10 May 2005 01:10:05 GMT From: Ian Dowse <iedowse@iedowse.com> To: freebsd-usb@FreeBSD.org Subject: Re: usb/80829: possible panic when loading USB-modules Message-ID: <200505100110.j4A1A50q018603@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR usb/80829; it has been noted by GNATS. From: Ian Dowse <iedowse@iedowse.com> To: hselasky@c2i.net Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: usb/80829: possible panic when loading USB-modules Date: Tue, 10 May 2005 02:07:20 +0100 In message <200505091849.15420.hselasky@c2i.net>, Hans Petter Selasky writes: > >There is a special mechanism where probe/attach can clear an entry in the >array pointed to by "uaa->ifaces". The existing USB-driver allocates the >"uaa" in memory, but the "uaa->ifaces" is still on the stack ! This is going >to cause a panic for some devices when loaded as a module. > >usbd_status >usbd_probe_and_attach(device_ptr_t parent, usbd_device_handle dev, > int port, int addr) > >... > usbd_interface_handle ifaces[256]; /* 256 is the absolute max */ > >... > uaa.ifaces = ifaces; Hi, Is there actually problem with any current usage of uaa.ifaces? I can see that the pointer to the ifaces[] array on the stack can get stored in the malloc'd `uaap' structure, but I couldn't see anywhere that actually references the ifaces[] array after usbd_probe_and_attach() returns - I'm probably missing something simple though. If nothing needs to use uaap->ifaces[] then I guess just setting it to NULL at the end of usbd_probe_and_attach() would make it clear that it is no longer valid? If there is some case where the stack array is referenced after usbd_probe_and_attach() returns, then it would be very helpful if you could post a quick description of how that can happen. Thanks, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505100110.j4A1A50q018603>