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]

Date:	Mon, 13 May 2013 16:20:17 -0700
From:	Anton Vorontsov <anton@...msg.org>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Kosina <jkosina@...e.cz>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] HID: input: return ENODATA if reading battery attrs fails

On Mon, May 13, 2013 at 05:01:30PM +0200, David Herrmann wrote:
[..]
> I really dislike the way power_supply core calls into the drivers during the
> "add" uevent. If a driver holds an I/O mutex (or anything else), it might
> even deadlock in a very non-obvious way. Is there a reason why we need to
> pass _all_ battery properties along "add" and "remove" uevents? Isn't it
> enough to pass them with "change" uevents? This would guarantee that the
> power_supply callbacks are only called from user-context and "change" events.

I don't think that there is a particular reason for that, but if you want
to change that, then I'd suggest to still keep uevent reporting of all the
properties on "add" and "remove" events, but don't actually call the
drivers' callback, just assume ENODATA.

This way we well preserve the behaviour of the older kernels, so that
userland will not break if, for example, it allocates needed memory on
"add" event, and then assumes that "change" will follow the pattern.

Thanks,

Anton
--
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/