Comment # 7 on bug 1231836 from Wenruo Qu

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