netdev - Re: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG

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: <1458586269.9609.14.camel@suse.com>
Date:	Mon, 21 Mar 2016 19:51:09 +0100
From:	Oliver Neukum <oneukum@...e.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
	Woojung Huh <woojung.huh@...rochip.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Guenter Roeck <linux@...ck-us.net>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
> 
> > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> > 
> > > One possible solution is to export a sysfs parameter to prevent 
> > > statistics collection (or more generally, to change the interval at 
> > > which it occurs).
> > 
> > Surely, not performing a task can hardly be beaten in terms of power
> > consumption. That is not meant to be flippant, but I think these
> > issues are orthogonal. The question of how much to do doesn't
> > solve the question of doing efficiently what we do.
> 
> In other words, what's the best way to collect the statistics without 
> interfering with runtime PM, right?

Yes.

> If the device is suspended, presumably we know there's nothing to
> collect -- especially if we already collected the statistics at the
> time the device got suspended.  Hence my suggestion to avoid querying 
> the device while it is suspended.

That is perfectly alright if we just collect statistics.
As a generic mechanism it is bad. Think about the polling
for media detection.

> But this leaves open the issue that querying the device too often will 
> prevent it from going into autosuspend.  It seems to me that the best 
> way to deal with this is to make sure that the autosuspend timeout is 
> shorter than the interal between queries, not to make the querying 
> conditional on !runtime_auto.
[..]
> > If we know when the next activity will come, why not pass this
> > information down?

We have an autosuspend timeout because we think that IO, if it will
come at all, is likeliest to come soon. If, however, the IO is
periodic that heuristics is false.
To save most power the driver must either decide that the interval
is too short or suspend immediately. So if we are lucky enough
to have the frequency in the kernel, we should use that information.

	Regards
		Oliver