Date: Tue, 27 Mar 2018 17:09:06 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: geom->access problem and workaround Message-ID: <356b875d-baee-c60b-fa76-531d3de22676@FreeBSD.org> In-Reply-To: <CANCZdfppefRHeLf8tKQyJ9BS8a0fO99d7jKM4=v0N16GQ7wAbA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?356b875d-baee-c60b-fa76-531d3de22676>