On Thu 19-10-23 10:33:36, Christian Brauner wrote: > On Wed, Oct 18, 2023 at 05:29:24PM +0200, Jan Kara wrote: > > The implementation of bdev holder operations such as fs_bdev_mark_dead() > > and fs_bdev_sync() grab sb->s_umount semaphore under > > bdev->bd_holder_lock. This is problematic because it leads to > > disk->open_mutex -> sb->s_umount lock ordering which is counterintuitive > > (usually we grab higher level (e.g. filesystem) locks first and lower > > level (e.g. block layer) locks later) and indeed makes lockdep complain > > about possible locking cycles whenever we open a block device while > > holding sb->s_umount semaphore. Implement a function > > This patches together with my series that Christoph sent out for me > Link: https://lore.kernel.org/r/20231017184823.1383356-1-hch@xxxxxx > two days ago (tyvm!) the lockdep false positives are all gone and we > also eliminated the counterintuitive ordering requirement that forces us > to give up s_umount before opening block devices. > > I've verified that yesterday and did a bunch of testing via sudden > device removal. > > Christoph had thankfully added generic/730 and generic/731 to emulate > some device removal. I also messed around with the loop code and > specifically used LOOP_CHANGE_FD to force a disk_force_media_change() on > a filesystem. Ah, glad to hear that! So now we can also slowly work on undoing the unlock s_umount, open bdev, lock s_umount games we have introduced in several places. But I guess let's wait a bit for the dust to settle :) Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
