critical kernel panic on 4.2 (or any other version) on hammer volume-del

[Tomohiro Kusumi]

There is a critical kernel panic issue while running hammer volume-del.
I've seen this happens not only on master, but also 4.2.4 release kernel
(which was before I started to touch hammer volume-add|del ioctl code) and
probably older kernels too from the way it works.

This seems to be a timing issue, race between ioctl called by a volume-del
process and the flusher kernel thread. It's relatively easy to reproduce in
my environment with >=4 volumes but never with 2 or 3 volumes. The first
one or two volumes need to be filled up and make reblock run before
unloading the volume in order to reproduce this.

In the worst case, a volume gets removed and volume header gets erased as
usual, but kernel could panic before volume count of remaining volumes get
updated (decremented). This results in inconsistency between volume count
and # of valid volumes, and the filesystem will no longer be mountable
unless directly edit the volume header of block devices.

I haven't fixed this yet, nor is it obvious, but it seems the flusher
kernel thread needs to be aware of ongoing volume-del by checking if
hmp->volume_to_remove != -1
similar to the way blockmap allocator checks it while looking for free
space within a bigblock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20150901/275ae904/attachment.htm>