Re: [RFC] possible badness in prune_dcache()

[Josef Bacik <jbacik@redhat.com>]

On Fri, Apr 04, 2008 at 06:28:46PM +0300, Alex Lyashkov wrote:
> Thanks for answer,
> 
> Yes this commit - fix issue with umount, but not resolve main question:
> why prune_dcache kill dentry with diffrent super block? this produce
> long loop with skip loop instead of early exit and move dentry from
> select_parent again to end of list.
>

probably worth looking at doing something different in the case of shrinking the
dcache on the parent, and leaving prune_dcache to only be called in the case of
trying to free up dcache under memory pressure, where the superblock doesn't
actually matter.  For the RHEL3 issue you are reffering to I fixed it by
creating a private list when we shrunk the parent, and submitting that list to
prune_dcache that way we didn't spend all this time looping.  I will see what
can be done for upstream.

Josef

> 
> On Fri, 2008-04-04 at 14:42 +0200, Miklos Szeredi wrote:
> > > When investigation livelock in RHEL3, i found possible badness in
> > > prune_dcache, which exist in 2.6.24 also.
> > 
> > Have you actually tested with 2.6.24?  shrink_dcache_parent() isn't
> > called from umount anymore.  I think this is the commit responsible
> > for fixing the issue:
> > 
> > commit c636ebdb186bf37f98d3839f69293597723edb36
> > Author: David Howells <dhowells@redhat.com>
> > Date:   Wed Oct 11 01:22:19 2006 -0700
> > 
> >     [PATCH] VFS: Destroy the dentries contributed by a superblock on unmounting
> > 
> > Miklos
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html