linux-kernel - Re: [PATCH][input-led] Defer input led work to workqueue

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: <3942.1409078958@turing-police.cc.vt.edu>
Date:	Tue, 26 Aug 2014 14:49:18 -0400
From:	Valdis.Kletnieks@...edu
To:	Samuel Thibault <samuel.thibault@...-lyon.org>
Cc:	Hugh Dickins <hughd@...gle.com>, akpm@...ux-foundation.org,
	Sabrina Dubroca <sd@...asysnail.net>,
	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: [PATCH][input-led] Defer input led work to workqueue

On Tue, 26 Aug 2014 03:54:53 +0200, Samuel Thibault said:
> This changeset defers the second led_trigger_event call into a
> workqueue, which avoids the nested locking altogether.  This does
> not prevent the user from shooting himself in the foot by creating a
> vt::capsl <-> vt-capsl loop, but the only consequence is the workqueue
> threads eating some CPU until the user breaks the loop, which is not too
> bad.
>
> Signed-off-by: Samuel Thibault <samuel.thibault@...-lyon.org>
>
> --- a/drivers/input/leds.c
> +++ b/drivers/input/leds.c
> @@ -100,13 +100,25 @@ static unsigned long vt_led_registered[B

I admit having zero understanding of the code, but I can confirm that
next-20140825 still throws the lockdep whine I was seeing, but the same
tree with this patch on top of it boots without warning. Soo...

Tested-By: Valdis Kletnieks <valdis.kletnieks@...edu>

Content of type "application/pgp-signature" skipped