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: <aCNiiHzOksQFrPe1@black.fi.intel.com>
Date: Tue, 13 May 2025 18:17:28 +0300
From: Raag Jadav <raag.jadav@...el.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: rafael@...nel.org, mahesh@...ux.ibm.com, oohall@...il.com,
	bhelgaas@...gle.com, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, ilpo.jarvinen@...ux.intel.com,
	aravind.iddamsetty@...ux.intel.com
Subject: Re: [PATCH v3] PCI: Prevent power state transition of erroneous
 device

On Tue, May 13, 2025 at 06:41:31AM +0200, Lukas Wunner wrote:
> On Sun, May 04, 2025 at 02:34:44PM +0530, Raag Jadav wrote:
> > If error flags are set on an AER capable device, most likely either the
> > device recovery is in progress or has already failed. Neither of the
> > cases are well suited for power state transition of the device, since
> > this can lead to unpredictable consequences like resume failure, or in
> > worst case the device is lost because of it. Leave the device in its
> > existing power state to avoid such issues.
> 
> Have you witnessed this on a particular platform / hardware combination?
> If so, it would be good to mention it.  If I'd happen to find this
> commit in the future through "git blame", that's the first question
> that would come to mind:  How and on what hardware was this actually
> triggered, how can I reproduce it.

We have a few issues[1] reported which are similar in nature. But since
they are not easily reproducible and still under investigation, I'm
a bit hesitant to explicitly reference it.

[1] https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4395

> > +	/*
> > +	 * If error flags are set on an AER capable device, most likely either
> > +	 * the device recovery is in progress or has already failed. Neither of
> > +	 * the cases are well suited for power state transition of the device,
> > +	 * since this can lead to unpredictable consequences like resume
> > +	 * failure, or in worst case the device is lost because of it. Leave the
> > +	 * device in its existing power state to avoid such issues.
> > +	 */
> 
> That's quite verbose and merely a 1:1 repetition of the commit message.
> I'd recommend a more condensed code comment and anyone interested in
> further details may look them up in the commit message.

Sure, will update.

Raag

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ