usb/80829: possible panic when loading USB-modules

[Ian Dowse]

The following reply was made to PR usb/80829; it has been noted by GNATS.

From: Ian Dowse <iedowse at iedowse.com>
To: hselasky at c2i.net
Cc: FreeBSD-gnats-submit at 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 at 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