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: <4C80B81F.8090803@gmail.com>
Date:	Fri, 03 Sep 2010 10:55:59 +0200
From:	Tejun Heo <htejun@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
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>,
	Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>
Subject: Re: [linux-pm] [PATCH] libata: skip EH autopsy and recovery during
 suspend

cc'ing Jens and Christoph and quoting whole body for them.

On 09/02/2010 11:01 PM, Alan Stern wrote:
> 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?

Hmm... I can't really tell much without looking at the actual patch
but I'm a bit doubtful about using REQ_TYPE_* for suspend/resumes,
well, for that matter, for any other purpose than actual IO requests.
The current REQ_TYPE_PM_* are only used by ide and it's really messy.

Those special requests are very difficult to use in generic manner.
ie. How should remapping / cloning drivers like md, dm and loopback
handle them?  They end up just being a mechanism for specific low
level drivers to feed certain requests back to themselves to implement
suspend/resume sequence and as there's no clear defined common usage,
the meaning of those flags becomes ambiguous and confusing depending
on drivers and so on.

Another issue is that power management is probably better handled as a
sub problem of generic IO exception handling.  If you throw in
hot[un]plugs and transport errors and consider what should happen when
those events happen together, things get hairy if power management is
not well integrated with the usual exceptionn handling.

Thanks.

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