Messages in this thread | | | Date | Tue, 20 Dec 2005 07:33:41 -0600 | From | Cliff Wickman <> | Subject | Re: Very rare crash in prune_dcache |
| |
Hi Bharata,
On Tue, Dec 20, 2005 at 12:16:29PM +0530, Bharata B Rao wrote: > Hi Cliff, > > > I suspect a race condition inside prune_dcache(). > > > > The prune_dcache() function: > > lock dcache_lock > > scan the dentry_unused list of dentry's for a given number ("count") of > > dentry's to free: -------- get (remove) dentry from dentry_unused list -------- > > if a dentry to free, call prune_one_dentry() > > dentry_iput() > > unlock dcache_lock > > iput() any associated inode > > d_free() the dentry > > lock dcache_lock > > unlock dcache_lock > > > > Two processors entering prune_dcache() near the same time will both scan > > the dentry_unused list and could try to iput() the same inode twice. That is > > because the dcache_lock is released while running iput(). > > Isn't this what dcache_lock doing presently ? As per vanilla 2.6.5 kernel > I don't see how the race condition you mention above can happen. > > In prune_dcache(), a dentry is first removed off the dentry_unused list > (under dcache_lock) before calling prune_one_dentry(). So how is it > possible that an another thread executing prune_dcache() will hit > the same dentry again ?
Yes, I think you're right. And it's not theoretically possible for two dentry's to point to the same inode. So the inode that caused our crash must have been corrupted elsewhere. Thanks.
-Cliff
-- Cliff Wickman Silicon Graphics, Inc. cpw@sgi.com (651) 683-3824 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |