lkml.org 
[lkml]   [2005]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-12-20 14:36    [W:0.043 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site