geom->access problem and workaround

[Warner Losh]

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

On 23/03/2018 15:31, Warner Losh wrote:
>
>
> On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon <avg at freebsd.org
> <mailto:avg at freebsd.org>> 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
blocking
>     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
0xfffff801e58b8048
>     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
to
the normal state only then the driver would start processing queued I/O
requests.
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.

Warner