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