linux-kernel - Re: Stop SSD from waiting for "Spinning up disk..."

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: <20150625162143.GA27230@khazad-dum.debian.net>
Date:	Thu, 25 Jun 2015 13:21:43 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Jeff Chua <jeff.chua.linux@...il.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Stop SSD from waiting for "Spinning up disk..."

On Mon, 22 Jun 2015, Jeff Chua wrote:
> There's no need to wait for disk spin-up for USB SSD devices. This patch

No, you have to, instead, wait for SSD firmware startup.

And looking at the contents of sd_spinup_disk(), I don't think it is safe to
just skip it, either.  It would be be better to call it sd_start_device()...

sd_spinup_disk() should be really fast on anything that properly implements
TEST_UNIT_READY and returns "ok, I am ready" when it doesn't need further
waits or START_STOP, etc...

Anyway, if you get to see the "Spinning up disk..." printk, your unit did
not report it was ready, and sd_spinup_disk tried to issue a START_STOP
command to signal it to get ready for real work.

There's at least one msleep(1000) in the START_STOP path, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/