linux-kernel - Re: [git patches] libata hibernation fixes

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: <49110817.60000@kernel.org>
Date:	Wed, 05 Nov 2008 11:42:31 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git patches] libata hibernation fixes

Linus Torvalds wrote:
>  - maybe we just do something odd and different, triggering some BIOS 
>    behavior that isn't there under Windows.
>    So we should power down thigns differently so that the BIOS.

These HP machines require patched storage driver to avoid the same
problem, so it's not a generic problem and Windows is doing its own
blacklisting in its own way.

>  - quite possibly: we just should not spin down disks at all, and just 
>    flush them and do the "park" command thing. If we're _really_ powering 
>    off, the disks will spin down on their own when power goes away. Maybe 
>    that's what Windows does?

I'm fairly sure they do about the same thing we do (FLUSH followed by
STANDBY_IMMEDIATE).  The only problem we've seen regarding harddrive
shutdown or suspend sequence is a BIOS wrongfully assuming the
controller is turned on and goes bonkers on suspend (this, we might want
to change, not much point in turning off all the PCI controllers before
entering suspend, is there?) and these HP machines which like to issue
STANDBY_IMMEDIATE of its own and also breaks on stock Windows.

> So I really don't want to pull this, because I want to get more of an 
> explanation for why we need to do this at all. I also don't think this is 
> even appropriate at this stage in -rc.

They were supposed to go in during -rc1 but there was a misunderstanding
while handing off patches I collected during Jeff's vacation and they
got lost inbetween.  I apologize for the late submission but this
problem can shorten life span of hard drives considerably && applies
only to a small set of machines, so I hope this can go in for 2.6.28.

> Is it a regression? If so, that just strengthens the questions above - 
> what did _we_ start doing wrong that this is needed at all? Let's just 
> stop doing that, not add some idiotic black-list for somethign that _we_ 
> do wrong.

It's a regression in a sense that a long while ago, libata didn't do any
spindown at all, which, again, was a regression from drivers/ide.  So,
the question whether this problem is a regression or not is sort of
irrelevant here.  It's plainly a ugly workaround for ugly hardware
situation and Windows does it in even uglier way.

Thanks.

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