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: <20070124153727.GC15402@khazad-dum.debian.net>
Date:	Wed, 24 Jan 2007 13:37:27 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Soeren Sonnenburg <kernel@....de>
Cc:	Tejun Heo <htejun@...il.com>, Jeff Garzik <jeff@...zik.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: SATA hotplug from the user side ?

On Wed, 24 Jan 2007, Soeren Sonnenburg wrote:
> might be a good idea to power down the drive using hdparm -Y followed by
> a scsiadd -r.

Unfortunately, I don't think this will be the optimal way to do it for long.
Unless I am mistaken, the above will soon have the potential to spin down
the device, and then reset the device to wake it up again (through error
handling, thus causing error messages in syslog) to send it a spin down
command(!).  It will work well right now, because scsiadd -r is unable to
shutdown a device and just removes it.

In the future, you will need to do *either* one, not both, if you told the
kernel to shutdown SCSI devices (which distros will likely enable by
default, as it is the right setup for everyone but people with servers
with disks attached to multi-initiator SCSI buses and it is required for
suspend-to-disk to work).

It will be a mess to make sure everything in userspace is updated to not try
to hdparm -y (or worse, hdparm -Y) devices that the kernel will shutdown by
itself, but it will make things a lot better for the future.

Unless...

Tejun, is it feasible to teach libata to check the device power management
state before issuing any of the sleep, head unload and spin-down commands?

libata would need to block its EH from resetting a channel for this check
operation (we don't want to wake up sleeping devices to ask it if it is
sleeping...) if it cannot easily check if an device is asleep before issuing
a command to it.   Either that, or (for as long as there is no such a thing
as a multi-initiator libata device) just keep track of the device power
management state by snooping all the commands sent to it.

The idea would be to do the "optimal" thing if one tries to sleep, unload
heads or spin down an device that is already doing one of these things...
That would make things MUCH easier on userspace.

> BIG FAT WARNING: if your SATA bay does not do electrical connector
> keying to let the disk firmware unload heads before the user manages to

This either is in the SATA specification, or it is not, and according to
Tejun it probably isn't (if it were, all disks would do the right thing at
unplug).  I'd reword it to "if your SATA bay does not take extra steps to
force the disk firmware to unload heads...".

> the disk or remove the disk from a dm setup). However it is recommended
> to power down the drive using hdparm -Y followed by a scsiadd -r as
> stated above. One can validate which disks are attached using ``scsiadd

Again, this might change soon.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ