Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Apr 2011 08:27:14 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Bartosz Fabianowski <freebsd@chillt.de>
Subject:   Re: Is there some implicit locking of device methods?
Message-ID:  <5627117D-499B-4FD7-BF84-BE4BE6F583D7@bsdimp.com>
In-Reply-To: <201104260942.03543.jhb@freebsd.org>
References:  <4DB695DB.1080505@chillt.de> <201104260942.03543.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5627117D-499B-4FD7-BF84-BE4BE6F583D7>