lkml.org 
[lkml]   [2006]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (updated patch)
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()?
-
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: 2006-03-09 12:26    [W:0.131 / U:0.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site