Re: Very rare crash in prune_dcache

[Cliff Wickman]

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@xxxxxxx
(651) 683-3824
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/