Re: Reviewing determinism of xfs_reclaim_inodes_ag()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 26-04-17 11:12:06, Luis R. Rodriguez wrote:
> On Wed, Apr 26, 2017 at 10:04:26AM +1000, Dave Chinner wrote:
> > On Tue, Apr 25, 2017 at 10:25:03AM +0200, Luis R. Rodriguez wrote:
> > > I checked with Jan Kara and he believes the current code is correct but that
> > > its the comment that that may be misleading. As per Jan the race is between
> > > getting an inode reclaimed and grabbing it. Ie, XFS frees the inodes by RCU.
> > > However it doesn't actually *reuse* the inode until RCU period passes
> > > (unlike inodes allocated from slab with SLAB_RCU can be). So it can happen
> > 
> > ..... I initially tried using SLAB_DESTROY_BY_RCU which meant the
> > RCU grace period did not prevent reallocation of inodes that had
> > been freed. Hence this check was (once) necessary to prevent the
> > reclaim index going whacky on a reallocated inode.
> 
> Alright this helps, but why does *having* the RCU grace period prevent
> such type of race ? I can see it helping but removing completely such
> a race as a possibility ?

Well, if the inode is freed only after RCU period expires and we are doing
xfs_reclaim_inode_grab() under rcu_read_lock - which we are - then this
surely prevents us from seeing inode reallocated. What are you missing?

> Also, just so I understand I am following, this then implicates our
> reclaim rate is directly linked to the RCU grace period ?

Yes, as for any RCU-freed object...

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux