Date: Fri, 23 Mar 2018 12:38:44 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: geom->access problem and workaround Message-ID: <5e416eb6-0e79-1419-f09a-eb747215dc28@FreeBSD.org> In-Reply-To: <56619.1520878022@critter.freebsd.dk> References: <809d9254-ee56-59d8-69a4-08838e985cea@FreeBSD.org> <CANCZdfpPGXbKnMfuXWJFVk3xpk-hj8%2BtnsscbySeQTOrB2M-9w@mail.gmail.com> <56619.1520878022@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
cpuid = 0
curthread: 0xfffff80008e1c000
time = 1521652565
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff804670bb = db_trace_self_wrapper+0x2b/frame
0xfffffe07e1886750
kdb_backtrace() at 0xffffffff806d4c79 = kdb_backtrace+0x39/frame 0xfffffe07e1886800
vpanic() at 0xffffffff80699da6 = vpanic+0x166/frame 0xfffffe07e1886840
kassert_panic() at 0xffffffff80699adb = kassert_panic+0x16b/frame 0xfffffe07e18868b0
sleepq_add() at 0xffffffff806e1902 = sleepq_add+0x342/frame 0xfffffe07e1886910
_sleep() at 0xffffffff806a41f7 = _sleep+0x2b7/frame 0xfffffe07e18869b0
cam_periph_ccbwait() at 0xffffffff802b53ad = cam_periph_ccbwait+0x5d/frame
0xfffffe07e18869e0
cam_periph_runccb() at 0xffffffff802b51d8 = cam_periph_runccb+0xb8/frame
0xfffffe07e1886a40
cdrunccb() at 0xffffffff802d52fc = cdrunccb+0x3c/frame 0xfffffe07e1886a60
cdprevent() at 0xffffffff802d4beb = cdprevent+0x7b/frame 0xfffffe07e1886aa0
cdcheckmedia() at 0xffffffff802d48b2 = cdcheckmedia+0x22/frame 0xfffffe07e1886af0
cdstrategy() at 0xffffffff802d2a36 = cdstrategy+0x56/frame 0xfffffe07e1886b20
g_disk_start() at 0xffffffff80608330 = g_disk_start+0x170/frame 0xfffffe07e1886b70
g_io_schedule_down() at 0xffffffff8060c1db = g_io_schedule_down+0x1eb/frame
0xfffffe07e1886b90
g_down_procbody() at 0xffffffff8060cbdd = g_down_procbody+0x6d/frame
0xfffffe07e1886ba0
fork_exit() at 0xffffffff8065e410 = fork_exit+0xd0/frame 0xfffffe07e1886bf0
fork_trampoline() at 0xffffffff808e4aee = fork_trampoline+0xe/frame
0xfffffe07e1886bf0
But maybe I am overgeneralizing.
Maybe it's just silly that cdstrategy tries perform media manipulations instead
of just failing a request. Apparently the device was already opened, but the
prevent-allow bit was changed by something else (e.g. via the pass device) and
that allowed to get the tray opened.
What do you think?
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5e416eb6-0e79-1419-f09a-eb747215dc28>