Hi. I found a suspected deadlock bug from ext4.
ext4_fill_super() releases and re-takes BKL while s_umount is held.
Lock ordering at the point where BKL is re-taken is s_umount-> BKL.
However, at do_remount(), locking ordering is BKL->s_umount.
Therefore, concurrent execution of do_remount() and ext4_fill_super()
may result deadlock.
Please examine this report. Thank you.
p.s. I found this suspected bug by the motivation from
commit 5f22ca9b13551debea77a407a8d06cd9c6f15238.
Hello,
> Hi. I found a suspected deadlock bug from ext4.
>
> ext4_fill_super() releases and re-takes BKL while s_umount is held.
> Lock ordering at the point where BKL is re-taken is s_umount-> BKL.
>
> However, at do_remount(), locking ordering is BKL->s_umount.
> Therefore, concurrent execution of do_remount() and ext4_fill_super()
> may result deadlock.
Hmm, I don't see how this could deadlock since we seem to take kernel
lock only in do_new_mount() before calling do_kern_mount(). But you are
right that taking the kernel lock with s_umount_sem looks fishy...
> p.s. I found this suspected bug by the motivation from
> commit 5f22ca9b13551debea77a407a8d06cd9c6f15238.
From a quick look, this looks like a different matter - they have used
lock_super() instead of lock_kernel() and that's used in more places.
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs