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

[Matthew Dillon]

Well, I'm amazed the volume-add/volume-del work at all.  It was coded way
back in 2009 by Michael Neumann (I think), but only a few people ever used
it so the feature has never seen the same sort of use or load that other
features have seen.

It would be pretty cool if you could get the volume add/del stuff working
reliably.

If you post the backtrace I might have some ideas on what the timing issue
between the flusher and the volume-del code could be.

-Matt

On Mon, Aug 31, 2015 at 12:10 PM, Tomohiro Kusumi <kusumi.tomohiro at gmail.com
> wrote:

> 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/20150831/56561f04/attachment-0002.html>