Date: Tue, 10 May 2005 11:34:13 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: usb/80829: possible panic when loading USB-modules Message-ID: <200505101134.14381.hselasky@c2i.net> In-Reply-To: <20050509.144546.74694206.imp@bsdimp.com> References: <200505091849.15420.hselasky@c2i.net> <200505092220.42970.hselasky@c2i.net> <20050509.144546.74694206.imp@bsdimp.com>
index | next in thread | previous in thread | raw e-mail
On Monday 09 May 2005 22:45, Warner Losh wrote:
> > I'm planning to use the stack method and have usbd_probe_and_attach()
> > called again from uhub_explore() via a call similar to usb_explore().
> > Leaving devices after usbd_probe_and_attach() has returned, will _not_
> > work, except for generic or specific USB drivers. It will not work for
> > "ums", "ukbd" and so on, because a device can have more than one
> > configuration, and it is not sure that the right configuration index is
> > set when usbd_probe_and_attach() returns after the generic probe. Have a
> > look at this (almost finished):
> >
> > Implement a new state-variable "udev->probed" and a refcount in
> > "usbd_port" to limit the calling of "usbd_probe_and_attach()".
> >
> > Any comments?
>
> That can't work. The problem is that if there's no driver loaded, the
> device_t sticks around (and must stick around).
My idea is to not have any device_t stick around. The only reason that the
device_t must stick around, in the existing driver, is that they will get
probed via "bus_generic_driver_added" when a new driver is added.
So change:
DEVMETHOD(bus_driver_added, bus_generic_driver_added),
back into:
DEVMETHOD(bus_driver_added, uhub_driver_added),
And have "uhub_driver_added" call , say, "usbd_probe_and_attach_all()", that
will create device_t again and probe/attach, through "uhub_explore" and
"usb_event_thread", and free if no device present. And if this is done right,
it will not conflict with device removal! If you use
"bus_generic_driver_added", won't there be a race condition where a device
can be probed/attached at the same time it is detached, because probe/attach
can call USB-functions that can sleep, like usbd_do_request()? When sleeping
no lock is held.
> When the driver is
> then loaded, we look at all the unattached devices again and at that
> point the memory that's reference has to be stable. That's why I made
> the change in the first place.
>
> 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.
When you are loading an USB-module, because device_t is still sticking around,
probe/attach can be called outside of "usbd_probe_and_attach()", actually
from "bus_generic_driver_added". But in my opinion the uaaxxx structures
should not be available after probe/attach, and that probe/attach should not
be called outside of "usbd_probe_and_attach()".
--HPS
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505101134.14381.hselasky>