linux-kernel - Re: [linux-pm] [PATCH] libata: skip EH autopsy and recovery during suspend

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: <Pine.LNX.4.44L0.1009021646510.1311-100000@iolanthe.rowland.org>
Date:	Thu, 2 Sep 2010 17:01:20 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tejun Heo <htejun@...il.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@...il.com>,
	"linux-pm@...ts.osdl.org" <linux-pm@...ts.osdl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stephan Diestelhorst <stephan.diestelhorst@....com>
Subject: Re: [linux-pm] [PATCH] libata: skip EH autopsy and recovery during
 suspend

On Thu, 2 Sep 2010, Tejun Heo wrote:

> Hello,
> 
> On 09/02/2010 10:28 PM, Rafael J. Wysocki wrote:
> > That would be very nice.  In particular, I'd like to get rid of the
> > pm_message_t thing if possible.  And I'd like to avoid putting the
> > controller into D3 before creating hibernation image. :-)

Ultimately I don't think it will be possible to get rid of pm_message_t
throughout the entire kernel.  Not just because it's a legacy thing
spread all over the place, but because it sometimes is genuinely
useful.  In situations where there are only minimal differences between
the various suspend/resume paths, it makes a lot of sense to call a
single function and tell it which type of operation to perform.

> Oh, yeah, things like that can definitely be changed, but I think it
> would still need to be piped through EH.  That's how the queue gets
> quiesced for those special operations and resume is basically probing,
> so it doesn't make much sense to split them.  Please let me know how
> it should work from power management POV and I'll be happy to convert
> libata to fit the new behavior.

Tejun, I'm planning to make a few changes to the block layer and the
SCSI core in order to implement delayed autosuspend.  These changes
will affect system sleep too, so you may need to know about them.

Each request_queue structure will have an rpm_status variable that gets
updated as the corresponding device is suspended or resumed.  When the
status is SUSPENDING or RESUMING, requests will not be sent from the
request_queue to the driver unless they have cmd_type set to
REQ_TYPE_PM_SUSPEND or REQ_TYPE_PM_RESUME (actually I may combine those
two into a single REQ_TYPE_PM type).  If other types of request are
added to the queue when the status isn't ACTIVE, they will cause a
runtime resume to be started.

Initially this will affect only drivers using the SCSI layer.  
Commands sent during error handling won't be affected though, because
the SCSI error handler doesn't use requests or queues -- it sends
commands directly to the lower-level driver.

Does that all sound okay to you?

Alan Stern

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