Date: Tue, 27 Mar 2018 10:17:08 -0700 From: Warner Losh <imp@bsdimp.com> To: Andriy Gapon <avg@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org, freebsd-geom@freebsd.org Subject: Re: geom->access problem and workaround Message-ID: <CANCZdfo8-=kB%2B0OMqYJQejcJq8LbS_ChKxmKZ%2BREPd1CXJTBtw@mail.gmail.com> In-Reply-To: <356b875d-baee-c60b-fa76-531d3de22676@FreeBSD.org> References: <809d9254-ee56-59d8-69a4-08838e985cea@FreeBSD.org> <CANCZdfpPGXbKnMfuXWJFVk3xpk-hj8%2BtnsscbySeQTOrB2M-9w@mail.gmail.com> <56619.1520878022@critter.freebsd.dk> <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> <CANCZdfppefRHeLf8tKQyJ9BS8a0fO99d7jKM4=v0N16GQ7wAbA@mail.gmail.com> <356b875d-baee-c60b-fa76-531d3de22676@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 27, 2018 7:09 AM, "Andriy Gapon" <avg@freebsd.org> wrote:
On 23/03/2018 15:31, Warner Losh wrote:
>
>
> On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon <avg@freebsd.org
> <mailto:avg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo8-=kB%2B0OMqYJQejcJq8LbS_ChKxmKZ%2BREPd1CXJTBtw>