linux-kernel - Re: [PATCH] HID: input: return ENODATA if reading battery attrs fails

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: <CANq1E4TirOvzsGCXdVFboXWqeFPJYQF3+hp-C8cLYOVsnCFuYQ@mail.gmail.com>
Date:	Fri, 24 May 2013 16:02:06 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Daniel Nicoletti <dantti12@...il.com>
Cc:	"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>, Anton Vorontsov <cbou@...l.ru>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] HID: input: return ENODATA if reading battery attrs fails

Hi

On Mon, May 13, 2013 at 11:17 PM, Daniel Nicoletti <dantti12@...il.com> wrote:
> 2013/5/13 David Herrmann <dh.herrmann@...il.com>:
>> Anyway, I'd still like to see this patch applied so we have this annoying
>> bug fixed. I'd be willing to change the power_supply core, too, if one of the
>> maintainers agrees on the design (David? Anton?).
>>
>> And, @Daniel, can you check whether this actually fixes the bug? I don't own
>> a device that reports battery-information, but it at least fixes the same bug
>> for the hid-wiimote driver (tested by me).
>
> Yes, it does fixes the bug. Now udevadm properly show add and remove events
> and upower happily get's them.
> But there is around  15 seconds block on the bluetooth stack, in other words
> when connecting a device it seems to probe the device which blocks till
> a timeout, and while that timeout doesn't finish other bluetooth
> devices are also
> blocked. It seems the devices aren't able to be probed so soon, possibly
> because bluetooth didn't finished setting them up. Looking at udevadm output
> I clearly see that it locks for around 3 times.
> My kernel knowledge is rather limited but if you can give me tips or patches to
> test I really want to see this code finally working properly, and sorry for
> not realizing when I sent it that it had this issue...

The block occurs because power_supply core now tries all properties in
a row instead of aborting if the first fails (which is what we want).
However, bluetooth-core didn't allow I/O during probe so the timeout
got quite huge considering 3s for 5 different properties instead of 3s
once (which no-one noticed, yet..)

This is now fixed with the HIDP-patch pending on linux-input and
linux-bluetooth. For usbhid and uhid we already allow I/O during probe
so this does not happen there.

So I hope we can apply this for linux-next (probably after gustavo
applied the HIDP fix)?
Cheers
David
--
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/