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] [day] [month] [year] [list]
Date:	Thu, 8 Jan 2009 00:02:54 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Len Brown <lenb@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Matthew Wilcox <matthew@....cx>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, Greg KH <greg@...ah.com>,
	Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [RFC][PATCH 5/10] PCI PM: Avoid touching devices behind bridges in unknown state (rev. 2)

On Wednesday 07 January 2009, Pavel Machek wrote:
> On Mon 2009-01-05 14:30:54, Rafael J. Wysocki wrote:
> > On Monday 05 January 2009, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > Subject: PCI PM: Avoid touching devices behind bridges in unknown state (rev. 2)
> > > > From: Rafael J. Wysocki <rjw@...k.pl>
> > > > 
> > > > It generally is better to avoid accessing devices behind bridges that
> > > > may not be in the D0 power state, because in that case the bridges'
> > > > secondary buses may not be accessible.  For this reason, during the
> > > > early phase of resume (ie. with interrupts disabled), before
> > > > restoring the standard config registers of a device, check the power
> > > > state of the bridge the device is behind and postpone the restoration
> > > > of the device's config space, as well as any other operations that
> > > > would involve accessing the device, if that state is not D0.
> > > 
> > > I'm not sure if this is good idea.
> > > 
> > > Either pci config space needs to be restored early, or it can wait.
> > > 
> > > Sometimes restoring it early and sometimes restoring it late seems
> > > harmful: it will make code harder to understand and harder to test.
> > 
> > Unfortunately, we need to restore it early at least for some devices (bridges
> > and PCI Express ports) and I don't think it is generally safe to go and restore
> > it early for every device (as explained in this changelog).
> 
> Could we make it so that it is restored early exactly on bridges and
> PCIe ports?
> 
> Idea that restore of one specific device is called early or late
> depending if it is connected directly or behind bridge scares me...

There's nothing scary in it IMO and in fact the device's config space is
always restored as soon as reasonably possible.

It will be restored early even if it is behind a bridge, unless that bridge
itself is in a low power state, in which case clearly we _can't_ restore it
early.

Thanks,
Rafael
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ