linux-kernel - Re: 3.17-rc1: leds blink workqueue causes sleeping BUGs

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, 25 Aug 2014 15:00:44 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Samuel Thibault <samuel.thibault@...-lyon.org>,
	Sabrina Dubroca <sd@...asysnail.net>, Valdis.Kletnieks@...edu,
	Hugh Dickins <hughd@...gle.com>,
	Vincent Donnefort <vdonnefort@...il.com>,
	Bryan Wu <cooloney@...il.com>, linux-leds@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: 3.17-rc1: leds blink workqueue causes sleeping BUGs

On Mon, 25 Aug 2014, Samuel Thibault wrote:
> Samuel Thibault, le Mon 25 Aug 2014 23:23:24 +0200, a écrit :
> > We could indeed have a loop if the user was making the VT::* leds use
> > the vt-* trigger,
> 
> Actually, while there can be a loop, it wouldn't be possible to inject
> events in it: a VT::* led only makes the corresponding vt-* trigger if
> it got an event from its trigger, etc. So it's really a false positive,
> the lock detector just can not know that it can not happen.

I'm not suffering from this lockdep warning myself; but, false positive
or not, it does need to be fixed (or annotated).  Because once lockdep
reports one issue, it turns itself off.  So any developer who hits this
warning is then unable test their own changes with lockdep afterwards.

Hugh