Re: [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (updated patch)

[Andrew Morton <akpm@osdl.org>]

Jan Blunck <jblunck@suse.de> wrote:
>
> > This change might conflict with the NFS patches in -mm.
>  > 
> 
>  Hmm, right. Andrew, if you want a rediff against -mm just tell me. I'm
>  actually diff'ing against lates linux-2.6.git.

I'll work it out.

Are we all happy with this patch now?

<looks at it>

Cosmetically, I don't think wait_on_prunes() should be concerned about
whether or not it "slept".  That action is not significant and preemptible
kernels can "sleep" at just about any stage.  So I think the concept of
"slept" in there should be replaced with, say, "prunes_remaining" or
something like that.  Consequently the all-important comment over
wait_on_prunes() should be updated to provide a bit more information about
the significance of its return value, please.

Also I think there should be some explanation somewhere which describes why
we can continue to assume that there aren't any prunes left to do after
wait_on_prunes() has dropped dcache_lock.  I mean, once you've dropped the
lock it's usually the case that anything which you examined while holding
that lock now becomes out-of-date and invalid.  I assume the thinking is
that because there's an unmount in progress, nothing can come in and add
new dentries?

IOW: why isn't there a race between wait_on_prunes() and prune_one_dentry()?