linux-kernel - Re: [PATCH v2 1/3] Input: export LEDs as class devices in sysfs

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:	Tue, 21 Jul 2015 23:08:50 +0200
From:	Pavel Machek <pavel@....cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Vlastimil Babka <vbabka@...e.cz>,
	Samuel Thibault <samuel.thibault@...-lyon.org>,
	Pali Rohár <pali.rohar@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	rpurdie@...ys.net, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 1/3] Input: export LEDs as class devices in sysfs

On Tue 2015-07-21 10:01:33, Dmitry Torokhov wrote:
> On Tue, Jul 21, 2015 at 01:14:39PM +0200, Vlastimil Babka wrote:
> > On 06/09/2015 07:42 PM, Dmitry Torokhov wrote:
> > > From: Samuel Thibault <samuel.thibault@...-lyon.org>
> > > 
> > > This change creates a new input handler called "leds" that exports LEDs on input
> > > devices as standard LED class devices in sysfs and allows controlling their
> > > ptate via sysfs or via any of the standard LED triggers. This allows to
> > > re-purpose and reassign LDEs on the keyboards to represent states other
> > > than the standard keyboard states (CapsLock, NumLock, etc).
> > > 
> > > The old API of controlling input LEDs by writing into /dev/input/eventX
> > > devices is still present and will take precedence over acessing via LEDs
> > > subsystem (i.e. it may override state set by a trigger). If input device is
> > > "grabbed" then requests coming through LED subsystem will be ignored.
> > > 
> > > Signed-off-by: Samuel Thibault <samuel.thibault@...-lyon.org>
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > > ---
> > 
> > > +	led_no = 0;
> > > +	for_each_set_bit(led_code, dev->ledbit, LED_CNT) {
> > > +		struct input_led *led = &leds->leds[led_no];
> > > +
> > > +		led->handle = &leds->handle;
> > > +		led->code = led_code;
> > > +
> > > +		if (WARN_ON(!input_led_info[led_code].name))
> > > +			continue;
> > > +
> > 
> > Hi,
> > I get several warnings on booting 4.2-rc2 here. Should I be worried?
> > 
> > [    2.782432] ------------[ cut here ]------------
> > [    2.782440] WARNING: CPU: 2 PID: 356 at ../drivers/input/input-leds.c:115 input_leds_connect+0x22b/0x260()
> > [    2.782441] Modules linked in: btrfs xor raid6_pq crc32c_intel radeon i2c_algo_bit sr_mod cdrom drm_kms_helper ttm e1000e drm xhci_pci ptp pps_core xhci_hcd sg
> > [    2.782453] CPU: 2 PID: 356 Comm: kworker/2:2 Not tainted 4.2.0-rc2-1.g288d56b-desktop #1
> > [    2.782454] Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A13 03/27/2013
> > [    2.782458] Workqueue: usb_hub_wq hub_event
> > [    2.782459]  ffffffff81a917b7 ffff880213ecf298 ffffffff8169f19d 0000000000000007
> > [    2.782462]  0000000000000000 ffff880213ecf2d8 ffffffff810674f6 ffff880213ecf2f8
> > [    2.782463]  ffff8802132fb000 0000000000000003 000000000000000b ffff8800369ff000
> > [    2.782465] Call Trace:
> > [    2.782470]  [<ffffffff8169f19d>] dump_stack+0x4c/0x6e
> > [    2.782474]  [<ffffffff810674f6>] warn_slowpath_common+0x86/0xc0
> > [    2.782476]  [<ffffffff810675ea>] warn_slowpath_null+0x1a/0x20
> > [    2.782478]  [<ffffffff8152ccdb>] input_leds_connect+0x22b/0x260
> > [    2.782480]  [<ffffffff815281b2>] input_attach_handler+0x1a2/0x1f0
> > [    2.782483]  [<ffffffff81528640>] input_register_device+0x440/0x4f0
> > [    2.782486]  [<ffffffff8156e494>] hidinput_connect+0x334/0x5d0
> > [    2.782488]  [<ffffffff815683d4>] hid_connect+0x324/0x400
> 
> No, this is benign. I guess your keyboard has more LEDs than input
> system has defined or several usages refer to the same LED.

Can we get rid of WARN_ON, then? It is nasty to flood logs, and people
are likely to flood our inboxes, soon. printk(KERN_ERR) should be
adequate...

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/