geom->access problem and workaround

Warner Losh imp at
Tue Mar 27 17:17:12 UTC 2018

On Mar 27, 2018 7:09 AM, "Andriy Gapon" <avg at> wrote:

On 23/03/2018 15:31, Warner Losh wrote:
> On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon <avg at
> <mailto:avg at>> wrote:
>     On 12/03/2018 20:07, Poul-Henning Kamp wrote:
>     > If we want to have an architectural sound way to do slow operations
>     > before any "user-I/O" is initiated, the right way to do so is to
>     > define new BIO_OPEN and BIO_CLOSE  operation, and insist via asserts
>     > than all BIO_{READ|WRITE|DELETE} are wrapped in these.
>     In support of this proposal I want to add another example.
>     The problem is not only with doing I/O in access, but also with doing
>     I/O in the normal I/O path.
>     The following happened when a userland program tried to read from a
CD-ROM while
>     its tray was open:
>     panic: sleepq_add: td 0xfffff80008e1c000 to sleep on wchan
>     with sleeping prohibited
> cdstrategy shouldn't be sleeping. It can start I/O, but it can't wait for
it to
> finish. strategy has been a no-sleep-zone since at least v6. The fact it's
> waiting for prevent is the bug here.

I guess that what you suggest is that cdstrategy should place the incoming
request on a queue and then start a state machine for issuing management
commands and handling their completions.  After the state machine goes back
the normal state only then the driver would start processing queued I/O
Something like that?

Yes. Something like that. If we have to restart the discovery state
machine, that has to freeze the queues until that is done.


More information about the freebsd-arch mailing list