linux-kernel - Re: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 locks_free_lock

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: <20150113082001.0fa0d723@tlielax.poochiereds.net>
Date:	Tue, 13 Jan 2015 08:20:01 -0500
From:	Jeff Layton <jeff.layton@...marydata.com>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Jeff Layton <jeff.layton@...marydata.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236
 locks_free_lock_context+0x10d/0x240()

On Tue, 13 Jan 2015 00:11:37 -0500
Sasha Levin <sasha.levin@...cle.com> wrote:

> Hey Jeff,
> 
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following spew:
> 
> [  887.078606] WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 locks_free_lock_context+0x10d/0x240()
> [  887.079703] Modules linked in:
> [  887.080288] CPU: 16 PID: 4296 Comm: trinity-c273 Not tainted 3.19.0-rc4-next-20150112-sasha-00053-g23c147e02e-dirty #1710
> [  887.082229]  0000000000000000 0000000000000000 0000000000000000 ffff8804c9f4f8e8
> [  887.083773]  ffffffff9154e0a6 0000000000000000 ffff8804cad98000 ffff8804c9f4f938
> [  887.085280]  ffffffff8140a4d0 0000000000000001 ffffffff81bf0d2d ffff8804c9f4f988
> [  887.086792] Call Trace:
> [  887.087320] dump_stack (lib/dump_stack.c:52)
> [  887.088247] warn_slowpath_common (kernel/panic.c:447)
> [  887.089342] ? locks_free_lock_context (fs/locks.c:236 (discriminator 3))
> [  887.090514] warn_slowpath_null (kernel/panic.c:481)
> [  887.091629] locks_free_lock_context (fs/locks.c:236 (discriminator 3))
> [  887.092782] __destroy_inode (fs/inode.c:243)
> [  887.093817] destroy_inode (fs/inode.c:268)
> [  887.094833] evict (fs/inode.c:574)
> [  887.095808] iput (fs/inode.c:1503)
> [  887.096687] __dentry_kill (fs/dcache.c:323 fs/dcache.c:508)
> [  887.097683] ? _raw_spin_trylock (kernel/locking/spinlock.c:136)
> [  887.098733] ? dput (fs/dcache.c:545 fs/dcache.c:648)
> [  887.099672] dput (fs/dcache.c:649)
> [  887.100552] __fput (fs/file_table.c:227)
> [  887.101437] ____fput (fs/file_table.c:245)
> [  887.102317] task_work_run (kernel/task_work.c:125 (discriminator 1))
> [  887.103356] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:154 kernel/locking/spinlock.c:183)
> [  887.104390] do_exit (kernel/exit.c:746)
> [  887.105338] ? task_numa_work (kernel/sched/fair.c:2218)
> [  887.106384] ? get_signal (kernel/signal.c:2207)
> [  887.107492] ? _raw_spin_unlock_irq (./arch/x86/include/asm/paravirt.h:819 include/linux/spinlock_api_smp.h:170 kernel/locking/spinlock.c:199)
> [  887.108610] do_group_exit (include/linux/sched.h:775 kernel/exit.c:858)
> [  887.109613] get_signal (kernel/signal.c:2358)
> [  887.110578] ? trace_hardirqs_off (kernel/locking/lockdep.c:2671)
> [  887.111672] do_signal (arch/x86/kernel/signal.c:703)
> [  887.112604] ? acct_account_cputime (kernel/tsacct.c:168)
> [  887.113722] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:144 (discriminator 2))
> [  887.114937] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2578 kernel/locking/lockdep.c:2625)
> [  887.116128] ? trace_hardirqs_on (kernel/locking/lockdep.c:2633)
> [  887.117160] do_notify_resume (arch/x86/kernel/signal.c:750)
> [  887.118167] int_signal (arch/x86/kernel/entry_64.S:587)
> 
> 

Huh...

Looks like the flc_flock list wasn't empty when we went to go free the
inode. I don't see how that would happen right offhand, but I'll keep
looking at it.

Just to be clear -- were there any "exotic" filesystems involved here?
In particular any that define a ->flock inode operation (e.g. NFS) ?

Thanks for the report...
-- 
Jeff Layton <jlayton@...marydata.com>
--
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/