KDL on use of /bin/mountvolume (and multiple images)

[jonas.kirilla]

I was trying capture the output of /bin/mountvolume (having restarted Tracker in a Terminal) to show what mountvolume prints when launched on 10 images and it fails to mount some of them, when Haiku KDL:ed. Two consecutive tries resulted in a KDL.

[jonas.kirilla]

mountvolume.txt is from hrev32305

Lines of interest in mountvolume.cpp:

​http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#459 ​http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#476

​http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#192 ​http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#195

Today I've had no crash yet, but Tracker, Deskbar and Terminal hung (on filesystem access?) after having tried the same mountvolume thing.

[axeld]

So far, I could only reproduce the hang (which is a dead lock in the disk device manager's device watcher).

Have you used the "force unmount" feature while trying to reproduce this bug?

[axeld]

The dead lock should be fixed in hrev32526. I've seen the crash now, too, without having force unmounted anything.

[jonas.kirilla]

Thanks, I will try it out soon.

I don't think I tried force unmounting. The hang or crash would happen on opening the images via Tracker (and so having them mounted by mountvolume). When the images -did- mount successfully I don't think I ever had any problem unmounting. (Either by selecting the volume(s) and pressing Alt-U, or opening the image(s) again (having mountvolume unmount it/them.)

[anevilyak]

Just a note, hrev32526 had a regression in it that was fixed in hrev32820. Please review to ensure it doesn't reintroduce the deadlock, though as far as I can tell it should be safe.

[jonas.kirilla]

With hrev32822/trunk two sessions of testing (out of two) have ended in KDL. See attachment. I haven't seen a deadlock with this revision.

Procedure: I create 8 images sized 20MB on the desktop, using dd if=/dev/zero, format these as BFS using mkfs, select all 8 images and start pressing Alt-O repeatedly. This will mount and unmount all 8 images. If you repeat Alt-O too fast it crashes. This is with SMP.

[jonas.kirilla]

Repeating the above procedure (but with hrev32822/r1alpha1 on a single-cpu box) results in a bunch of mountvolume threads stuck in the kernel. One mountvolume thread holds the vfs_mount_op_lock and the other ones are waiting for it. The thread that holds the lock has a zzz(zzz) state(next state), sigpending 0x100000 (blocked 0x0) and waiting for: snooze().

[axeld]

(In #4833) The hang is probably a duplicate of #4223. Please alway only mention one bug per ticket.

[waddlesplash]

Anyone seen or managed to reproduce this since 9 years ago?

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed