Re: potential data race on `delayed_rsv->full`

[David Sterba <dsterba@suse.cz>]

On Fri, Nov 01, 2019 at 02:16:07PM -0400, Josef Bacik wrote:
> On Fri, Nov 01, 2019 at 01:09:30PM -0400, Meng Xu wrote:
> > Hi David,
> > 
> > Thank you for the confirmation and the additional information.
> > 
> > I feel the same that this race may not lead to serious issues, but would
> > rather prefer a confirmation from the developers. Thank you again for your
> > time!
> > 
> 
> Sorry I saw this while I was on vacation, I read through and determined that
> there were no cases where this would bite us.  This is just used as a lock free
> way to see if we should refill the delayed refs rsv.  Worst case we don't and
> the next guy does it, it doesn't affect us in an practical way.
> 
> However given our recent fun with inode->i_size it may be worth it to wrap
> access to ->full with WRITE_ONCE/READ_ONCE to make sure nothing squirrely
> happens in the future.  Thanks,

->full is used unlocked only in this one place, everywhere else it's
insde spinlock. With exception of
btrfs_clear_space_info_full/__find_space_info where it's only RCU
protection. Add in ONCE everywhere would be pointless, the one call can
be commented but adding READ_ONCE would not change anything as it's the
only access that must be loaded anyway.