linux-kernel - Re: [RFC] Asynchronous suspend/resume

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:	Mon, 21 Dec 2009 15:00:56 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Alan Stern <stern@...land.harvard.edu>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [RFC] Asynchronous suspend/resume - test results

On Mon, 21 Dec 2009, Rafael J. Wysocki wrote:
> 
> Do you think it's a good idea to mark all SCSI devices as async?  Well, for
> testing it probably is, but I doubt in general.

As long as things aren't multi-path, or multi-lun, it's probably fine.

With multi-path (ie same disk reachable multiple ways), it's probably fine 
too, but let's face it, who the hell knows? But it's not going to be an 
issue for laptops and normal desktops.

For multi-lun, I suspect the luns are related, and there might be some 
ordering issues. But it's _likely_ all fine there too.

The nice thing about systems with wires (ie USB, SCSI, SATA) is that it's 
really hard to make different devices have odd dependencies on each other. 
The wires tend to _be_ the topology.

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