linux-kernel - Re: processes hung after sys_renameat, and 'missing' processes

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]

Date:	Wed, 6 Jun 2012 21:19:15 -0400
From:	Dave Jones <davej@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Miklos Szeredi <mszeredi@...e.cz>, Jan Kara <jack@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: processes hung after sys_renameat, and 'missing' processes

On Wed, Jun 06, 2012 at 05:42:35PM -0700, Linus Torvalds wrote:

 > So Al meant you to test mutex_is_locked(dentry->d_inode->i_mutex) of
 > the parents.

ok, I ended up with..

        WARN_ON_ONCE(!mutex_is_locked(&target->d_parent->d_inode->i_mutex));

        if (dentry->d_parent != NULL)
                WARN_ON_ONCE(!mutex_is_locked(&dentry->d_inode->i_mutex));

but..
 
 > And I'd suggest making it just a WARN_ON_ONCE(), because if you make
 > it a BUG_ON() and it triggers, your system will likely be dead. And
 > ONCE is all that matters - it should never happen.

I hit the second WARN very early on, before I even get out of the initramfs.

[    6.365556] WARNING: at fs/dcache.c:2350 d_move+0xaf/0xc0()
[    6.365793] Modules linked in:
[    6.365909] Pid: 134, comm: mount Not tainted 3.5.0-rc1+ #69
[    6.366030] Call Trace:
[    6.366147]  [<ffffffff8104910f>] warn_slowpath_common+0x7f/0xc0
[    6.366271]  [<ffffffff8104916a>] warn_slowpath_null+0x1a/0x20
[    6.366396]  [<ffffffff811c5c4f>] d_move+0xaf/0xc0
[    6.366521]  [<ffffffff811b9654>] vfs_rename+0x3c4/0x4e0
[    6.366647]  [<ffffffff811bd741>] sys_renameat+0x201/0x230
[    6.366773]  [<ffffffff8132e59c>] ? debug_check_no_obj_freed+0x16c/0x210
[    6.366902]  [<ffffffff81171cfc>] ? vm_munmap+0x5c/0x80
[    6.367026]  [<ffffffff81086f91>] ? get_parent_ip+0x11/0x50
[    6.367148]  [<ffffffff81086f91>] ? get_parent_ip+0x11/0x50
[    6.367273]  [<ffffffff81651919>] ? sub_preempt_count+0x79/0xd0
[    6.367397]  [<ffffffff81655937>] ? sysret_check+0x1b/0x56
[    6.367521]  [<ffffffff810b7dd5>] ? trace_hardirqs_on_caller+0x115/0x1a0
[    6.367647]  [<ffffffff81326f4e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    6.367772]  [<ffffffff811bd78b>] sys_rename+0x1b/0x20
[    6.367891]  [<ffffffff81655912>] system_call_fastpath+0x16/0x1b

Did I screw up the test again ? I'm feeling a bit hard-of-thinking tonight.

 > > To be clear, do you want me to try that with or without the reverts ?
 >
 > I think either would be interesting. 

For now, I still have those two commits applied.

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