linux-kernel - Re: Changes to sysfs PM layer break userspace

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:	Tue, 19 Dec 2006 13:34:49 -0800
From:	David Brownell <david-b@...bell.net>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: Changes to sysfs PM layer break userspace

On Tuesday 19 December 2006 12:32 pm, Matthew Garrett wrote:
> On Tue, Dec 19, 2006 at 09:23:05PM +0100, Arjan van de Ven wrote:

> > right now the "spec" for Linux network drivers assumes that you put the
> > NIC into D3 on down, except for cases where Wake-on-Lan is enabled etc.
> 
> Really? I can't find any drivers that seem to do this. The only calls to 
> pci_set_power_state seem to be in the suspend, resume, init and exit 
> routines.

More drivers should do this, even though not many do so right now.  In the
ideal case, the PHY can be active for link detection without the rest of
the adapter being powered up...


> > > Some chips support more 
> > > fine-grained power management, so we could do something more sensible in 
> > > that case - but right now, there doesn't seem to be a lot of driver 
> > > support for it.
> > 
> > sounds like that's the right approach at least .. not talking to the PCI
> > hardware directly from userspace...
> 
> I'd certainly agree that that's the right thing to do, but userspace has 
> a habit of using whatever functionality /is/ available to get to a given 
> end. The semantics of the device/power/state file were never made 
> terribly clear, and it did have the desired effect of suspending the 
> device. Removing it without providing warning or a transition pathway is 
> a pain.

Documentation/feature-removal-schedule.txt has warned about this since
August, and the PM list has discussed how broken that model is numerous
times over the past several years.  (I'm pretty sure that discussion has
leaked out to LKML on occasion.)  It shouldn't be news today.


> > I can see the point of having more than just "UP" and "DOWN" as
> > interface states; "UP", "DOWN" and "OFF" for example... 
> 
> Agreed.

More than one driver stack probably needs to start paying attention to
its power management models.  I think Arjan is right about the basic
mindset of "down == off" for network drivers.  If there are cases where
that doesn't work, those can start driving improvements.

- Dave

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