Messages in this thread | | | Date | Thu, 9 Mar 2006 03:21:57 -0800 | From | Andrew Morton <> | Subject | Re: [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/
| |