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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
