https://bugzilla.suse.com/show_bug.cgi?id=1231836 https://bugzilla.suse.com/show_bug.cgi?id=1231836#c8 --- Comment #8 from Wenruo Qu <wqu@suse.com> --- (In reply to Wenruo Qu from comment #7)
(In reply to Fabian Vogt from comment #6)
(In reply to Wenruo Qu from comment #5)
The direct cause is, when the initial super RO flag mismatches, we got EBUSY and go btrfs_reconfigure_for_mount(), which flips our RO flag and retry.
But since the background process is also re-mounting which can flips the RO flag to a different one, we got -EBUSY again because the newly flipped RO flag conflicts with the newly remounted flag.
Heh, so I got a lucky guess!
This involves a lot of VFS calls which can be a little complex, but I'll try if we can do a mutex or something like that to avoid remount/mount to race on the same btrfs.
I saw your patch on the ML, which went into a different direction with more brute force...
Your approach of just retrying until no more -EBUSY probably works, but I wonder whether this retry loop is a good idea. In two cases it might retry indefinitely:
a) -EBUSY might be returned for other reasons (if not possible right now, maybe in the future?)
So far I didn't see any VFS function in the get_tree() and fc_mount() chain to return EBUSY.
My bad, get_vfs_tree() itself can return -EBUSY if fc->root is already populated. Thankfully unless something went wrong, fc->root should only be populated by the fs callbacks.
But I see your point, maybe we can change the return value to a more special one so that VFS layer is much harder to return a conflicting error number.
Although this means it's much more convincing to change the error number to a special one. -- You are receiving this mail because: You are on the CC list for the bug.