[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.11.1408251454570.26438@eggly.anvils>
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
Powered by blists - more mailing lists