On Mar 27, 2018 7:09 AM, "Andriy Gapon" <a...@freebsd.org> wrote:
On 23/03/2018 15:31, Warner Losh wrote: > > > On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon <a...@freebsd.org > <mailto:a...@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 _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
