linux-kernel - Re: [PATCH] PM / sleep: add configurable delay for pm

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:	Sun, 22 Feb 2015 00:24:29 +0100
From:	Pavel Machek <pavel@....cz>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	Brian Norris <computersforpeace@...il.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Len Brown <len.brown@...el.com>,
	Chirantan Ekbote <chirantan@...omium.org>
Subject: Re: [PATCH] PM / sleep: add configurable delay for pm_test

On Sat 2015-02-21 14:56:01, Florian Fainelli wrote:
> 2015-02-21 12:32 GMT-08:00 Pavel Machek <pavel@....cz>:
> >
> >
> >
> >> Considering that Brian's change are enclosed within a CONFIG_PM_DEBUG
> >> ifdef, can we really use the code bloat as a technical argument here?
> >
> > Yes.
> 
> Help me understand a few things here:

What you are missing is that we try to keep _sources_ small and
readable, too.

> - if we need to turn on PM_DEBUG all the time, including mainline
> distributions, does that mean that:
>            - portions of code existing only in PM_DEBUG should be
> moved out of it because it is actually useful outside of debug option?
>            - CONFIG_PM itself is not self sufficient and there are
> still problems that require PM_DEBUG to be turned on?
>            - should there be a second level debug option (e.g:
> CONFIG_PM_DEBUG_ADV) which gates specific control knobs like PM delay?
> 
> The current 5 seconds delay is completely arbitrary and goes against
> the principle of not enforcing a policy, having this configurable
> brings this back in the mechanism principle.

5 second delay is arbitrary, and slightly ugly debugging hack, that is
acceptable because it is useful, small and unobtrusive. The second you
add 40 lines of sysfs glue.. it is no longer small and unobtrusive,
and no longer acceptable.

And yes, distros probably ship with PM_DEBUG on, and no, adding
another config option would not make the big & ugly hack more
acceptable.

OTOH if you added a hook to kprobes that alowed easy binary patching
of the value "5" while not adding 40 lines of overhead, that might be
neccessary.

Actually, you can probably pull the address from System.map and then
just write to it using /dev/mem, no? Just arrange for "5" to be in
variable that is in System.map.

And you also want to check the kernel parameters, they are modifiable
in runtime in at least same cases.

But we are not adding 40 lines of uglyness. Clear?
									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/