There's more of the "delete from shrink list not owned by us" in select parent.
Proposed patch appended.
And I'm not sure what umount_collect() is supposed to do. Can other shrinkers
still be active at that point? That would present other problems, no?
Also somewhat related is the question: how check_submounts_and_drop() could be
guaranteed correctness (timely removal of all unsed dentries) in the presence of
other shrinkers?
Thanks,
Miklos
----
From: Miklos Szeredi <mszeredi@xxxxxxx>
Subject: dcache: select_collect(): don't remove from shrink list
Shrink lists are not protected by any lock, so don't remove from an unknown
one.
Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxx>
---
fs/dcache.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1241,18 +1241,19 @@ static enum d_walk_ret select_collect(vo
* loop in shrink_dcache_parent() might not make any progress
* and loop forever.
*/
- if (dentry->d_lockref.count) {
- dentry_lru_del(dentry);
- } else if (!(dentry->d_flags & DCACHE_SHRINK_LIST)) {
- /*
- * We can't use d_lru_shrink_move() because we
- * need to get the global LRU lock and do the
- * LRU accounting.
- */
+ if (dentry->d_flags & (DCACHE_SHRINK_LIST | DCACHE_LRU_LIST) ==
+ DCACHE_LRU_LIST) {
d_lru_del(dentry);
- d_shrink_add(dentry, &data->dispose);
- data->found++;
- ret = D_WALK_NORETRY;
+ if (!dentry->d_lockref.count) {
+ /*
+ * We can't use d_lru_shrink_move() because we
+ * need to get the global LRU lock and do the
+ * LRU accounting.
+ */
+ d_shrink_add(dentry, &data->dispose);
+ data->found++;
+ ret = D_WALK_NORETRY;
+ }
}
/*
* We can return to the caller if we have found some (this
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
