Re: [PATCH] Busy inodes after unmount, be more verbose in generic_shutdown_super

[Balbir Singh <balbir@in.ibm.com>]

> I think that in most cases, the race doesn't matter if
> shrink_dcache_memory misses a dentry because someone else is holding a
> temporary reference, it really doesn't matter.
> Similarly most callers of shrink_dcache_parent are happy with a
> best-effort.

I agree.

> 
> I should have been more explicit that the patch was against
> 2.6.16-rc5-mm2.  This contains some dcache patches to allow nfs
> filesystem to share superblocks, and one of the patches replaces the
> calls to shrink_dcache_parent and shrink_dcache_anon with a single
> call to a new function: shrink_dcache_sb.
>

shrink_dcache_parent() has been added back to generic_shutdown_super in
-mm3 (just checked). With that being the case, I have only one concern
with your patch

wait_on_prunes() breaks out if sb->prunes == 0. What if shrink_dcache_parent()
now calls select_parent(). select_parent() could still find entries 
with d_count > 0 and skip them and shrink_dcache_memory() can still cause
the race condition to occur.

I think pushing wait_on_prunes() to after shrink_dcache_parent() will
most likely solve the race.

 
> Thanks for the feedback

Your welcome!

> 
> NeilBrown

Balbir

-- 
I'm extremely grateful that hundreds of you have taken time to read these
patches, and to detect and report errors that you've found.
Your comments have helped me improve enormously. But I must confess that
I'm also disappointed to have had absolutely no feedback so far on several of
the patches on which I worked hardest when I was preparing these patches.
Could it be that (1) you've said nothing about them because I somehow managed
to get the details perfect? Or is it that (2) you shy away and are busy, hence
you are unable to spend more than a few minutes on any particular topic?
Although I do like to think that readers like to provide feedback, I fear that
hypothesis (1) is far less likely than hypothesis (2). 

Adapted from Don Knuth's comments on feedback for his exercises

-
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/