linux-kernel - Re: [Bug 3.4.5] reiserfs: mutex_destroy called with locked mutex

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: <CA+55aFzv5mntf6y9e_r5=v+beG19xBv67EpA=dP0-Zw1CQrGGg@mail.gmail.com>
Date:	Wed, 18 Jul 2012 09:26:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Knut Petersen <Knut_Petersen@...nline.de>,
	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org, reiserfs-devel@...r.kernel.org
Subject: Re: [Bug 3.4.5] reiserfs: mutex_destroy called with locked mutex

On Tue, Jul 17, 2012 at 10:26 PM, Knut Petersen
<Knut_Petersen@...nline.de> wrote:
> I hit the following problem during a heavy compile job on kernel 3.4.5:

I think it's triggered by the fact that reiserfs does

        d_instantiate(dentry, inode);
        unlock_new_inode(inode);

ie it does the "unlock_new_inode()" *after* it has already made the
inode visible to others in the filesystem. So you can now have a
concurrent lookup of that dentry that finds the (locked) inode before
"unlock_new_inode()" has had the chance to set the lockdep class.
Also, since it's been instantiated, the only *valid* inode pointer is
in the dentry, so the code really really shouldn't use the "inode"
pointer any more because the refcount has been transferred to the
dentry. So maybe memory pressure could turn the dentry negative (and
free the inode) while the unlock_new_inode() code runs.

fs/ext[23]/namei.c has the same pattern, though, and I think it should
be harmless (the inode is marked I_NEW and we get the i_lock for
unlock_new_inode, so the freeing code should know to keep away from
it). So I don't think the freeing code could trigger, but a concurrent
lookup then trying to look up the new directory (and taking the new
directory i_semaphore lock) could happen, afaik.

So I think we should re-order the d_instantiate/unlock_new_inode calls. Al?

                   Linus
--
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/