linux-kernel - Re: [PATCH 3/5] libata: Implement disk shock protection support

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

Message-ID: <48979039.4000000@gmail.com>
Date:	Tue, 05 Aug 2008 08:26:49 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Elias Oltmanns <eo@...ensachen.de>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, Jeff Garzik <jeff@...zik.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Pavel Machek <pavel@....cz>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] libata: Implement disk shock protection support

Elias Oltmanns wrote:
>>> I'm rather afraid this approach is impractical or unfavourable at the
>>> very least. Depending on the configured thresholds, a head unload
>>> request might well be issued unintentionally, e.g. by accidentally
>>> knocking against the table. It is quite alright for the HD to stop I/O
>>> for a moment but if the secondary device on the interface happens to be
>>> a CD writer, it will be very annoying to have CD writing operations fail
>>> due to minor percussions.
>> Why would it fail?
> 
> To be quite honest, I don't know very much about the way CD writing
> works. I just assumed that delaying queue processing for a CD writer for
> several seconds would have very much the same effect as the input buffer
> of cdrecord getting empty prematurely. Do you mean to say that CD
> writing (or any other time expensive operation I haven't thought of)
> won't be affected irrecoverably by interrupted command processing?

Any modern cd/dvd writer can happily recover from buffer underruns.  I
think the physical shock itself has better chance of screwing up the
recording.  The only thing to make sure is that no command is issued to
ATAPI devices.  Other than that, there should be no problem.

>>> Also, if there are two devices on the same
>>> port that support the UNLOAD FEATURE and you issue a head unload request
>>> to both of them in close succession, the IDLE IMMEDIATE to the second
>>> device will be blocked until the timeout for the first has expired.
>> Unload can be implemented as port-wide operation so that it issues IDLE
>> IMMEDIATE to all drives on the port but given that this is mostly for
>> laptop, this discussion is a bit peripheral.
> 
> We can't rule out that the HD is connected as master and CDRW as slave
> to the same controller in a PATA setup. I'm not familiar with the SATA
> configurations in modern laptops though.

On most, they occupy different channels and even when they reside on the
same channel, it just doesn't really matter these days.  And even on
those cases, it would be better to use EH as that will make the IDLE
IMMEDIATE command always win the bus as soon as possible while IDLE
IMMEDIATE queued at the head of the drive queue could lose to an ATAPI
command.

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/