When a xenstore watch triggers, the event is processed on process_msg
and if a valid handle it's found the handler is queued for execution
on the pending xen watches queue (watch_events).
This may present a problem if we trigger a xenwatch several times and
then disconnect the device. If several xenwatch events are added to
the watch_events queue and the device is disconnected afterwards, the
first processed xenwatch event will disconnect the device, remove the
watch and free all resources. This triggers a panic if there are
pending xenwatch events for that device already queued in the local
queue of the function xenwatch_thread, since when the next watch that
has the same handler tries to execute we get a panic due to the fact
that the device is already disconnected and all resources had been
freed:
xenbus_watch: 0xffffa0000b7cd1d0
xbw_callback: 0xffffffff80755dd4
otherend_changed: backend/vif/1/0
backend/vif/1/0/state 6
backend/vif/1/0 -> Closed
backend/vif/1/0 -> backend_device, b_detach: 0xffffffff8075a2bf
xenbus_watch: 0xffffa0000b7cd1d0
xbw_callback: 0xfc5ec02183e547a8
fatal protection fault in supervisor mode
trap type 4 code 0 rip ffffffff80756596 cs e030 rflags 10246 cr2
7f7ff7b4c020 ilevel 0 rsp ffffa000e6d82c50
curlwp 0xffffa0000a72d580 pid 0 lid 36 lowest kstack
0xffffa000e6d7f000
kernel: protection fault trap, code=0
Stopped in pid 0.36 (system) at netbsd:xenwatch_thread+0xc7: call
*10(%rax
)
xenwatch_thread() at netbsd:xenwatch_thread+0xc7
ds f
es 5987
fs 2c40
gs 1460
rdi ffffa0000b7cd1d0
rsi ffffa0000a5477f0
rbp ffffa000e6d82c70
rbx ffffa0000b7c14c0
rdx 2
rcx f
rax ffffa0000b7cd1d0
r8 78
r9 ffffffef
r10 deadbeef
r11 1
r12 ffffa000e6d82c50
r13 ffffa0000a72d580
r14 ffffa0000a72d580
r15 0
rip ffffffff80756596 xenwatch_thread+0xc7
cs e030
rflags 10246
rsp ffffa000e6d82c50
ss e02b
netbsd:xenwatch_thread+0xc7: call *10(%rax)
f301a1b2e9