linux-kernel - Re: PPS parport boot lockup: INFO: HARDIRQ-READ-safe -> HARDIRQ-READ-unsafe lock order detected

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:	Fri, 21 Jan 2011 08:37:34 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alexander Gordeev <lasaine@....cs.msu.su>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: PPS parport boot lockup: INFO: HARDIRQ-READ-safe ->
 HARDIRQ-READ-unsafe lock order detected

On Fri, Jan 21, 2011 at 6:44 AM, Alexander Gordeev
<lasaine@....cs.msu.su> wrote:
>
> But parport_unregister_device should probably never be called while
> parport interrupts are enabled (in hardware). So this is a false
> positive. Is this right?

"Enabled in hardware" is immaterial - with shared interrupts, it
doesn't matter one whit whether parport interrupts are disabled on the
chip, because some other chip may be using the same interrupt line.

So you'd need to have something that guarantees that there is no
concurrent use, like actually unregistering the irq handler itself.
Things like that can work.

HOWEVER, even then I think you should see the lockdep message as a
problem. The automated toolchain is great because it shows problems
that it thinks might happen - not when they happen, but based on a
simpler theoretical model. Ignoring the error because there is some
rule in place that is hard to explain to the automated toolchain is
the wrong thing to do, because it makes the lockdep automation less
reliable.

Think of it as a compiler warning - maybe the warning doesn't actually
imply an actual bug, but you should strive to write code that doesn't
warn, because otherwise the noise from the warning you ignored will
make it harder for others to see the _real_ bugs.

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