linux-kernel - Runtime PM for SCSI

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>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1002181529540.1269-100000@iolanthe.rowland.org>
Date:	Thu, 18 Feb 2010 15:54:22 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	SCSI development list <linux-scsi@...r.kernel.org>
cc:	USB Storage list <usb-storage@...ts.one-eyed-alien.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Runtime PM for SCSI

Developers have been receiving complaints about Linux's inability to
power-down card readers when they're not in use.  To address this issue
properly requires implementing runtime PM in the SCSI layer.  (For a
discussion of the current Runtime PM framework, see
Documentation/power/runtime_pm.txt.)

To begin with, it seems best to be safe: Don't suspend devices unless 
the device file is closed and there are no dirty buffers.  This last 
requirement arises because lots of USB card readers give spurious 
"Media may have changed" codes when resumed; if they had dirty buffers 
when suspended then the information would be lost.

Hence my first question: Can somebody tell me how to determine whether
a block device has any dirty buffers?  (And is there a particularly
good place in the SCSI layer or the block layer to test whether the
last dirty buffer has just been written out, or must this test be made
whenever a command completes?)

My second question: What are all the paths by which a command may be
added to the queue of a SCSI device whose file isn't open?  The
possibilities I'm aware of include:

	the sg driver (whose device file must itself be open);

	dirty-buffer writeback;

	the error handler thread;

	scsi_reset_provider().

Are there any others?

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/