linux-kernel - Re: kernel 3.1.1 / 3.1.0 reiserfs locking problems

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] [day] [month] [year] [list]

Message-ID: <20111115181553.GA3234@somewhere>
Date:	Tue, 15 Nov 2011 19:15:57 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Knut Petersen <Knut_Petersen@...nline.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, reiserfs-devel@...r.kernel.org,
	Greg KH <gregkh@...e.de>, Al Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jeff Mahoney <jeffm@...e.com>
Subject: Re: kernel 3.1.1 / 3.1.0 reiserfs locking problems

On Tue, Nov 15, 2011 at 02:59:21PM +0100, Knut Petersen wrote:
> Am 31.10.2011 16:08, schrieb Linus Torvalds:
> 
> With kernel 3.1.1 there is another reiserfs related lock probleme:
> 
> Nov 15 11:37:27 golem kernel: [ 1986.896976]
> Nov 15 11:37:27 golem kernel: [ 1986.896979] =================================
> Nov 15 11:37:27 golem kernel: [ 1986.896990] [ INFO: inconsistent lock state ]
> Nov 15 11:37:27 golem kernel: [ 1986.896997] 3.1.1-main #8
> Nov 15 11:37:27 golem kernel: [ 1986.897001] ---------------------------------
> Nov 15 11:37:27 golem kernel: [ 1986.897007] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
> Nov 15 11:37:27 golem kernel: [ 1986.897016] kswapd0/16 [HC0[0]:SC0[0]:HE1:SE1] takes:
> Nov 15 11:37:27 golem kernel: [ 1986.897023]  (&REISERFS_SB(s)->lock){+.+.?.}, at: [<c01f8bd4>] reiserfs_write_lock+0x20/0x2a
> Nov 15 11:37:27 golem kernel: [ 1986.897044] {RECLAIM_FS-ON-W} state was registered at:
> Nov 15 11:37:27 golem kernel: [ 1986.897050]   [<c014a5b9>] mark_held_locks+0xae/0xd0
> Nov 15 11:37:27 golem kernel: [ 1986.897060]   [<c014aab3>] lockdep_trace_alloc+0x7d/0x91
> Nov 15 11:37:27 golem kernel: [ 1986.897068]   [<c0190ee0>] kmem_cache_alloc+0x1a/0x93
> Nov 15 11:37:27 golem kernel: [ 1986.897078]   [<c01e7728>] reiserfs_alloc_inode+0x13/0x3d
> Nov 15 11:37:27 golem kernel: [ 1986.897088]   [<c01a5b06>] alloc_inode+0x14/0x5f
> Nov 15 11:37:27 golem kernel: [ 1986.897097]   [<c01a5cb9>] iget5_locked+0x62/0x13a
> Nov 15 11:37:27 golem kernel: [ 1986.897106]   [<c01e99e0>] reiserfs_fill_super+0x410/0x8b9
> Nov 15 11:37:27 golem kernel: [ 1986.897114]   [<c01953da>] mount_bdev+0x10b/0x159
> Nov 15 11:37:27 golem kernel: [ 1986.897123]   [<c01e764d>] get_super_block+0x10/0x12
> Nov 15 11:37:27 golem kernel: [ 1986.897131]   [<c0195b38>] mount_fs+0x59/0x12d
> Nov 15 11:37:27 golem kernel: [ 1986.897138]   [<c01a80d1>] vfs_kern_mount+0x45/0x7a
> Nov 15 11:37:27 golem kernel: [ 1986.897147]   [<c01a83e3>] do_kern_mount+0x2f/0xb0
> Nov 15 11:37:27 golem kernel: [ 1986.897155]   [<c01a987a>] do_mount+0x5c2/0x612
> Nov 15 11:37:27 golem kernel: [ 1986.897163]   [<c01a9a72>] sys_mount+0x61/0x8f
> Nov 15 11:37:27 golem kernel: [ 1986.897170]   [<c044060c>] sysenter_do_call+0x12/0x32

The most straightforward way to solve this is to unlock before getting the superblock
inode:

diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c
index 14363b9..463c203 100644
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1762,9 +1762,11 @@ static int reiserfs_fill_super(struct super_block *s, void *data, int silent)
 	}
 	args.objectid = REISERFS_ROOT_OBJECTID;
 	args.dirid = REISERFS_ROOT_PARENT_OBJECTID;
+	reiserfs_write_unlock(s);
 	root_inode =
 	    iget5_locked(s, REISERFS_ROOT_OBJECTID, reiserfs_find_actor,
 			 reiserfs_init_locked_inode, (void *)(&args));
+	reiserfs_write_lock(s);
 	if (!root_inode) {
 		SWARN(silent, s, "jmacd-10", "get root inode failed");
 		goto error;

But may be there are other iget5_locked in the path that I missed.

Note this should be a harmless warning because I guess the filesystem can't be
used for memory reclaim before it is actually mounted. But still this is
annoying and the above fix is one more hack to cope with the fact we need to
hold the lock from the mount path early even if we don't need it. That's
because many helpers used there assume the lock is always taken when they
are called. This assumption come from the bkl times.

So probably I should try to clean up this a bit to solve it in a less
dirty way. I'll try to come with something soon.
--
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/