https://bugzilla.suse.com/show_bug.cgi?id=1231836 https://bugzilla.suse.com/show_bug.cgi?id=1231836#c7 --- Comment #7 from Wenruo Qu <wqu@suse.com> --- (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. 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.
b) Something flips ro/rw all the time (rather artificial, but technically possible)
In that case we will eventually win the race, and we only need to win it once. The real blockage behind this is, we do not hold any super block, thus can not utilize the s_umount rwsem to do any synchronization. Maybe we can introduce an internal rwsem to handle this, but it's pretty hard to co-operate with the VFS and very bug-prone thus I do not think it's any better. -- You are receiving this mail because: You are on the CC list for the bug.