geom->access problem and workaround

[Andriy Gapon]

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