linux-kernel - Re: lockdep false positive? -- firewire-core transaction timer vs. scsi-core host 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: <1281996550.3683.43.camel@jlt3.sipsolutions.net>
Date:	Tue, 17 Aug 2010 00:09:10 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: lockdep false positive? -- firewire-core transaction timer vs.
 scsi-core host lock

On Mon, 2010-08-16 at 23:42 +0200, Peter Zijlstra wrote:

> Which means that it now worries the following can happen:
> 
> softirq:
>   spin_lock(&t->split_timeout_timer);
> 
> IRQ:
>   spin_lock(&(shost->host_lock)->rlock);
>    spin_lock(&t->split_timeout_timer);
> 
> Now, the thing is that split_timeout_timer is a fake lock used to
> annotate timers, its use is to connect lock chains from within the timer
> callback to del_timer_sync() callers, to detect deadlocks.
> 
> Now, I can't seem to remember why del_timer_sync() explicitly disables
> IRQs but call_timer_fn() does not, Johill, happen to remember?

Err, sorry, no. I do remember that we had long discussions and initially
I had wanted to disable the context checking for these fake locks
completely. I think it was just the minimal thing needed not to make it
warn always. Also, we can't do the same thing in call_timer_fn() since
we need to hold it across fn()? Wouldn't it complain if we held that
lock then while enabling IRQs again? Not sure.

I don't fully understand the scenario above yet though. Why does it
think we could ever take the fake lock in an IRQ to start with? That
must not happen. Or is that just preemptive worrying?

johannes

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