Messages in this thread | | | Date | Sat, 3 May 2014 19:21:11 +0100 | From | Al Viro <> | Subject | Re: dcache shrink list corruption? |
| |
On Sat, May 03, 2014 at 05:26:04AM +0100, Al Viro wrote:
> See vfs.git#dentry_kill-3; warning - this is completely untested and I would > really like comments on spinning case there (i.e. the one where select_collect() > finds some stuff already on some other shrink list and nothing with zero > refcount that wouldn't be there). In that case (and it's basically "somebody > else is evicting stuff in our subtree and they'd already picked everything > we want evicted") I just let the loop in check_submounts_and_drop() repeat > (we do have cond_resched() there). Any better suggestions would be welcome...
Hmm... As the matter of fact, the whole shrink_dcache_for_umount() could be made a lot saner. What we need is to reuse shrink_dcache_parent() and follow it with d_walk() that would just go through whatever remains and complain about the leaves of that. For anon roots we'll obviously need to wrap that into dget and d_drop/dput.
I'm testing that right now; everything seems to be working so far and if it survives, I'll push that sucker out. Total since the beginning of the whole series: fs/dcache.c | 310 ++++++++++++++++++++++++++++++++--------------------------------------------------------- include/linux/dcache.h | 2 + 2 files changed, 112 insertions(+), 200 deletions(-)
Anyway, I'm off to finish with acct.c races, then it's time for Eric's lazy umount on unlink series; this work is getting unpleasantly close to the areas he's touching, so I'd better get it on top of this stuff and into -next...
| |