Date: Tue, 26 Apr 2011 10:37:17 -0400 From: John Baldwin <jhb@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-hackers@freebsd.org, Bartosz Fabianowski <freebsd@chillt.de> Subject: Re: Is there some implicit locking of device methods? Message-ID: <201104261037.17893.jhb@freebsd.org> In-Reply-To: <5627117D-499B-4FD7-BF84-BE4BE6F583D7@bsdimp.com> References: <4DB695DB.1080505@chillt.de> <201104260942.03543.jhb@freebsd.org> <5627117D-499B-4FD7-BF84-BE4BE6F583D7@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, April 26, 2011 10:27:14 am Warner Losh wrote: > > On Apr 26, 2011, at 7:42 AM, John Baldwin wrote: > > - The Giant protection for new-bus should prevent attach/detach from running > > concurrently I believe (either that or the USB bus itself should ensure > > that the two instances of your device have seperate device_t instances with > > separate softc's, so current attach/detach should not matter except that > > they may both try to talk to the same hardware perhaps? In that case that > > is something the USB bus driver should fix by prevent a device from > > attaching at an existing address until any existing device at that address > > is fully detached). > > I thought that if we held Giant when we're about to go to sleep that we drop > it as a special case. So if any newbus-releated function sleeps, we can > have a situation where attach is running and detach gets called. There is > (or was) some code to cope with this in CardBus, iirc. I'm surprised there > isn't any in USB, since Hans was the one that alerted me to this issue. Yes, Giant doesn't really provide too much help here. However, the real fix should be in the USB bus, and USB peripheral drivers should not have to worry about handling concurrent attach/detach (they can't really handle it safely anyway). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104261037.17893.jhb>