linux-kernel - [PATCH 4/4] fs/inode.c: always take i_lock before calling filesystem's test() method

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1348219866-1799-5-git-send-email-yan@linux.vnet.ibm.com>
Date:	Fri, 21 Sep 2012 17:31:06 +0800
From:	Guo Chao <yan@...ux.vnet.ibm.com>
To:	viro@...iv.linux.org.uk
Cc:	dchinner@...hat.com, hch@...radead.org, jack@...e.cz,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 4/4] fs/inode.c: always take i_lock before calling filesystem's test() method

In insert_inode_locked4(), we call test() without i_lock held, it's
inconsistent with other places that calling test(). Though this
function is only used by reiserfs, in which case i_lock is unnecessary,
we should provide test() a consistent locking context.

This patch calls test() under the protection of i_lock in
insert_inode_locked4().

Signed-off-by: Guo Chao <yan@...ux.vnet.ibm.com>
---
 fs/inode.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 89d2bcc..4c7e6e2 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1312,9 +1312,11 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
 		hlist_for_each_entry(old, node, head, i_hash) {
 			if (old->i_sb != sb)
 				continue;
-			if (!test(old, data))
-				continue;
 			spin_lock(&old->i_lock);
+			if (!test(old, data)) {
+				spin_unlock(&old->i_lock);
+				continue;
+			}
 			if (old->i_state & (I_FREEING|I_WILL_FREE)) {
 				spin_unlock(&old->i_lock);
 				continue;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/