linux-kernel - Re: PM regression with LED changes in next-20161109

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: <20161114083118.GC18123@amd>
Date:   Mon, 14 Nov 2016 09:31:18 +0100
From:   Pavel Machek <pavel@....cz>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Jacek Anaszewski <j.anaszewski@...sung.com>,
        linux-leds@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Darren Hart <dvhart@...radead.org>
Subject: Re: PM regression with LED changes in next-20161109

Hi!

> >Also, how would we read the
> >brightness set by the firmware? We'd have to read brightness
> >file, so still two files would have to be opened which is
> >a second drawback of this approach.
> 
> No, look carefully at the definition of the read behavior
> I plan to put in the ABI doc:
> 
> "Reading this file will return the actual led brightness
> when not blinking and no triggers are active; reading this
> file will return the brightness used when the led is on
> when blinking or triggers are active."

That's not sane semantics. Userspace would have to read three files
(racy) to find out about triggers etc.

It also prevents modelling
"hardware-changes-brightness-behind-kernel's-back" as a trigger.

> So for e.g. the backlit keyboard case reading this single
> file will return the actual brightness of the backlight,
> since this does not involve blinking or triggers.

Stop obsessing about "ingle file". FDs are pretty cheap. This is sysfs.

> >Having no difference in this area between the two approaches
> >I'm still in favour of the read-only file for notifying
> >brightness changes procured by hardware.
> 
> That brings back the needing 2 fds problem; and does

Actually you have turned "2 fds" into "3 fds", as userspace now needs
to check for trigger _and_ blinking _and_ actuall brightness.

fds are cheap, but that is still not nice design.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)