On Wed, Dec 15, 2010 at 03:30:43AM +0000, Nick Piggin wrote:
> In this case, if you can observe something that has happened after the
> inode is removed from the tree (ie. i_ino has changed), then you should
> not find it in the tree after a subsequent lookup (no synchronize_rcu
> required, just appropriate locking or barriers).
Ok, that's what I thought was supposed to be the case. Thanks
for confirming that, Nick.
> BTW. I wondered if you can also do the radix_tree tag lookup for reclaim
> under RCU?
It's currently under the ->pag_ici_lock using a
radix_tree_gang_lookup_tag, though I think this was a mismerge bug
from an earlier version.
I intended it to be under RCU as the "inode OK for reclaim"
validation checks won't touch an inode that already has XFS_IRECLAIM
already set (i.e. already under reclaim or freed), so the
reliability of tag lookups is not a big deal.
The lookup probably needs to check if XFS_IRECLAIMABLE is set
(rather than asserting it is set) to avoid so as to only reclaim
inodes that are really in the reclaimable state. Note that
->i_flags_lock controls all the state changes, so it should provide
the necessary item memory barriers to ensure that only reclaimable
inodes are found for reclaim.