linux-kernel - Re: sched: spinlock recursion in sched_rr_get

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:	Mon, 7 Jul 2014 10:30:16 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: sched: spinlock recursion in sched_rr_get_interval

On Sun, Jul 06, 2014 at 01:27:37PM -0400, Sasha Levin wrote:
> Hi all,
> 
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
> 
> [10062.200152] BUG: spinlock recursion on CPU#11, trinity-c194/2414
> [10062.201897]  lock: 0xffff88010cfd7740, .magic: dead4ead, .owner: trinity-c194/2414, .owner_cpu: -1
> [10062.204432] CPU: 11 PID: 2414 Comm: trinity-c194 Not tainted 3.16.0-rc3-next-20140703-sasha-00024-g2ad7668-dirty #763
> [10062.207517]  ffff88010cfd7740 ffff8803a429fe48 ffffffffaa4897e4 0000000000000000
> [10062.209810]  ffff8803c35f0000 ffff8803a429fe68 ffffffffaa47df58 ffff88010cfd7740
> [10062.210024]  ffffffffab845c77 ffff8803a429fe88 ffffffffaa47df83 ffff88010cfd7740
> [10062.210024] Call Trace:
> [10062.210024] dump_stack (lib/dump_stack.c:52)
> [10062.210024] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 6))
> [10062.210024] spin_bug (kernel/locking/spinlock_debug.c:76)
> [10062.210024] do_raw_spin_lock (kernel/locking/spinlock_debug.c:84 kernel/locking/spinlock_debug.c:135)
> [10062.210024] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
> [10062.210024] ? task_rq_lock (include/linux/sched.h:2885 kernel/sched/core.c:348)
> [10062.210024] task_rq_lock (include/linux/sched.h:2885 kernel/sched/core.c:348)
> [10062.210024] SyS_sched_rr_get_interval (kernel/sched/core.c:4429 kernel/sched/core.c:4407)
> [10062.210024] ? tracesys (arch/x86/kernel/entry_64.S:531)
> [10062.210024] tracesys (arch/x86/kernel/entry_64.S:542)

Cute, but I'm utterly failing to see how that happened :/

All we should be holding there is the rcu_read_lock(), task_rq_lock()
there will take ->pi_lock and then rq->lock.

Maybe after more tea, when the brain wakes up more or so.. weird.

Content of type "application/pgp-signature" skipped