linux-kernel - Re: [RFC v2 PATCH 2/4] block: add queue runtime pm callbacks

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, 5 Jun 2012 13:27:42 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Lin Ming <ming.m.lin@...el.com>
cc:	Jens Axboe <axboe@...nel.dk>, Jeff Moyer <jmoyer@...hat.com>,
	<linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>,
	<linux-scsi@...r.kernel.org>
Subject: Re: [RFC v2 PATCH 2/4] block: add queue runtime pm callbacks

On Tue, 22 May 2012, Lin Ming wrote:

> > Next, you have to change the parts of the block layer responsible for
> > taking a request from the queue and handing it to the lower-level
> > driver (both peek and get).  If q->rpm_status is RPM_SUSPENDED, they
> > shouldn't do anything -- act as though the queue is empty.  If
> > q->rpm_status is RPM_SUSPENDING or RPM_RESUMING, they should hand over
> > the request only if it has the REQ_PM flag set.

I just realized this isn't quite right.  In fact, when the status is
RPM_SUSPENDING or RPM_RESUMING you need to search through the queue for
the first request with REQ_PM set.

Otherwise you can end up in a deadlock.  For example, suppose the
device is suspended and a normal I/O request arrives.  It gets put on
the queue and a runtime resume is issued.  The sd resume method then
submits a "spin-up drive" command to the queue with REQ_PM set, and it
doesn't return until this command is finished.  But the command won't
even start, because it isn't at the head of the queue -- the I/O
request is, and it prevents the "spin-up" command from running.

There are two other issues you also need to address.  The first is
simple: Make sure your changes don't cause any harm if CONFIG_PM or
CONFIG_PM_RUNTIME is set to N.

Second, near the end of scsi_pm.c:scsi_bus_resume_common(), you can see
that during resume from a system sleep, the device automatically gets
set back to RPM_ACTIVE.  You want the queue's runtime status to remain
in sync with the device's status; therefore you need to call
blk_pre_runtime_resume near the start of this function and
blk_post_runtime_resume near the end.  (This is the drawback of having
separate rpm_status fields for the queue and the device.)

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/