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: <1281997633.3683.50.camel@jlt3.sipsolutions.net>
Date:	Tue, 17 Aug 2010 00:27:13 +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:

> softirq:
>   spin_lock(&t->split_timeout_timer);
> 
> IRQ:
>   spin_lock(&(shost->host_lock)->rlock);
>    spin_lock(&t->split_timeout_timer);

Actually, I think it's worried that you could have


CPU 0                         CPU 1
 softirq:                      softirq:
   spin_lock(timer)              spin_lock(rlock)
 irq:
   spin_lock(rlock)
                                 spin_lock(timer) [still in softirq]

because it has previously seen the nesting that I put on CPU 1, and now
found that the timer "lock" is used with interrupts enabled.

At least that's a scenario I could understand?

I'm convinced it's a false positive though, question is how to shut it
up :-)

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/