Comment # 8 on bug 1231836 from Wenruo Qu

(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.