On Thu, Jun 28, 2018 at 07:22:59PM +0800, Anand Jain wrote:
> The circular locking dependency warning occurs at FSSTRESS_PROG.
> And in particular at doproc() in xfstests/ltp/fsstress.c, randomly
> at any of the command at
> opdesc_t ops[] = { ..}
> which involves calling mmap file operation and if there is something
> to commit.
>
> The commit transaction does need device_list_mutex which is also being
> used for the btrfs_open_devices() in the commit 542c5908abfe84f7.
>
> But btrfs_open_devices() is only called at mount, and mmap() can
> establish only be established after the mount has completed. With
> this give its unclear to me why the circular locking dependency check
> is warning about this.
>
> I feel until we have clarity about this and also solve other problem
> related to the streamlining of uuid_mutex, I suggest we revert
> 542c5908abfe84f7. Sorry for the inconvenience.
Ok, the revert is one option. I'm cosidering adding both the locks, like
is in https://patchwork.kernel.org/patch/10478443/ . This would have no
effect, as btrfs_open_devices is called only from mount path and the
list_sort is done only for the first time when there are not other
users of the list that would not also be under the uuid_mutex.
This passed the syzbot and other tests, so this does not break things
and goes towards pushing the device_list_mutex as the real protection
mechanism for the fs_devices members.
Let me know what you think, the revert should be the last option if we
don't have anything better.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
