From d895a1c96af8c2a0f6a5e0119695a7c6b92df8db Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Sun, 24 Oct 2010 19:40:24 +0200 Subject: [PATCH] fs: do not drop inode_lock in dispose_list Despite the comment above it we can not safely drop the lock here. invalidate_list is called from many other places that just umount. Also switch to proper list macros now that we never drop the lock. Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro --- fs/inode.c | 20 ++------------------ 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 09e2d7a5f1d2..1bf2be41257a 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -482,26 +482,10 @@ static void dispose_list(struct list_head *head) */ static int invalidate_list(struct list_head *head, struct list_head *dispose) { - struct list_head *next; + struct inode *inode, *next; int busy = 0; - next = head->next; - for (;;) { - struct list_head *tmp = next; - struct inode *inode; - - /* - * We can reschedule here without worrying about the list's - * consistency because the per-sb list of inodes must not - * change during umount anymore, and because iprune_sem keeps - * shrink_icache_memory() away. - */ - cond_resched_lock(&inode_lock); - - next = next->next; - if (tmp == head) - break; - inode = list_entry(tmp, struct inode, i_sb_list); + list_for_each_entry_safe(inode, next, head, i_sb_list) { if (inode->i_state & I_NEW) continue; if (atomic_read(&inode->i_count)) { -- 2.39.2