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

Message-ID: <87d4kooh4k.fsf@denkblock.local>
Date:	Mon, 04 Aug 2008 18:54:35 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Tejun Heo <htejun@...il.com>
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

Tejun Heo <htejun@...il.com> wrote:
> Elias Oltmanns wrote:
>>> For libata, the easiest way to achieve the above would be adding a
>
>>> per-dev EH action, say, ATA_EH_UNLOAD and schedule EH w/ the action OR'd
>>> to eh_info->action.  The EH_UNLOAD handler can then issue the command
>>> wait for the specified number of seconds and continue.  This will be
>>> pretty simple to implement as command exclusion and stuff are all
>>> automatically handled by EH framework.
>> 
>> 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?

>
>> 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.

Regards,

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