linux-kernel - Re: irq lock inversion

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

Message-ID: <alpine.LSU.2.00.0911051502060.9988@wotan.suse.de>
Date:	Thu, 5 Nov 2009 15:31:48 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>, cl@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: irq lock inversion


[ added LKML to CC so that the lockdep message is at least indexed by 
  search engines in archives ]

On Thu, 5 Nov 2009, Tejun Heo wrote:

> > lockdep only considers a lock irq-safe if it was used from an irq 
> > context before.
> > 
> > _irqsave() API usage alone does not trigger this.
> 
> Thanks for the explanation.  It's about the same tho.  sched_init() is
> calling it with irq disabled but that's an exception to might_sleep()
> rule.  Maybe making lockdep recognize the same exception as
> might_sleep() so that lockdep doesn't consider a lock irq-safe if it's
> called with irq off but before system_state is set to SYSTEM_RUNNING
> works around the problem?

Hmm, I wonder why I don't see this lockdep warning myself with 
head on 1836d9592, even though I have 

	CONFIG_PROVE_LOCKING=y
	CONFIG_TRACE_IRQFLAGS=y

... ?

Anyway, how about something like this? (I can't verify myself that it even 
fixes the warning, as I don't see it for some odd reason)




From: Jiri Kosina <jkosina@...e.cz>
Subject: lockdep: avoid false positives about irq-safety

Commit 403a91b1 ("percpu: allow pcpu_alloc() to be called
with IRQs off") introduced this warning:

	=========================================================
	[ INFO: possible irq lock inversion dependency detected ]
	2.6.32-rc5-tip-04815-g12f0f93-dirty #745
	---------------------------------------------------------
	hub 1-3:1.0: state 7 ports 2 chg 0000 evt 0004
	ksoftirqd/65/199 just changed the state of lock:
	 (pcpu_lock){..-...}, at: [<ffffffff81130e04>] free_percpu+0x38/0x104
	but this lock took another, SOFTIRQ-unsafe lock in the past:
	 (vmap_area_lock){+.+...}

	and interrupts could create inverse lock ordering between them.

This warning is bogus -- sched_init() is being called very early with IRQs
disabled, and the irqsave/restore code paths in pcpu_alloc() are only for early
init. The path can never be called from irq context once the early init
finishes. Rationale for this is explained in changelog of the commit mentioned
above.

This problem can be encountered generally in any other early code running
with IRQs off and using irqsave/irqrestore.

Reported-by: Yinghai Lu <yhlu.kernel@...il.com>
Signed-off-by: Jiri Kosina <jkosina@...e.cz>

--- 
 kernel/lockdep.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 9af5672..996b395 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2487,6 +2487,14 @@ void lockdep_trace_alloc(gfp_t gfp_mask)
 
 static int mark_irqflags(struct task_struct *curr, struct held_lock *hlock)
 {
+	/* 
+	 * This is exception similar to the might_sleep() one. 
+	 * We don't care about irq-safety of the locks this early, as
+	 * it will produce false positives (sched_init() is called with
+	 * irqs off, but needs to use irqsave/irqrestore API)
+	 */
+	if (system_state != SYSTEM_RUNNING)
+		return 1;
 	/*
 	 * If non-trylock use in a hardirq or softirq context, then
 	 * mark the lock as used in these contexts:
--
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/