I had a XEN3_DOM0 kernel crash after doing "umount -f /build" (which I did because "fstat /build" didn't find anything using that filesystem).
However there were several vnd(4) devices open by Xen domUs using files
on /build that I had completely forgotten about!
[ 178445.6211804] fatal integer divide fault in supervisor mode
[ 178445.6211804] trap type 8 code 0 rip 0xffffffff80936fb7 cs 0xe030
rflags 0x10246 cr2 0xffff9f82f9e21000 ilevel 0 rsp 0xffff9f8305c9ee00
[ 178445.6211804] curlwp 0xffff9f8020cd81c0 pid 0.1268 lowest kstack
0xffff9f8305c9a2c0
kernel: integer divide fault trap, code=0
Stopped in pid 0.1268 (system) at netbsd:vndthread+0x677: idivq
ffffffffffffff78(%rbp),%rax
vndthread() at netbsd:vndthread+0x677
ds edf0
es 0
fs 81c0
gs 800
rdi 0
rsi 6
rbp ffff9f8305c9eef0
rbx e0b0dc0
rdx 0
rcx 135
rax 0
r8 0
r9 97a7c
r10 ffff9f806119f040
r11 fffffffe
r12 0
r13 800
r14 ffff9f8021e3c800
r15 0
rip ffffffff80936fb7 vndthread+0x677
cs e030
rflags 10246
rsp ffff9f8305c9ee00
ss e02b
netbsd:vndthread+0x677: idivq ffffffffffffff78(%rbp),%rax
db{4}>
After a reboot we can see the vnd(4) uses:
# vndconfig -l
vnd0: /build (/dev/mapper/vg0-build) inode 861956
vnd1: /build (/dev/mapper/vg0-build) inode 861966
vnd2: /build (/dev/mapper/vg0-build) inode 861953
vnd3: not in use
So, might it be possible to have fstat show these somehow? (perhaps
with the/a kernel thread identified as having them open)
Also, is this a crash that should be fixed, or is "umount -f" always a
Buyer-Beware operation with expected "undefined behaviour"?
--
Greg A. Woods <gwo...@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
pgpciMYzV_vbE.pgp
Description: OpenPGP Digital Signature
