linux-kernel - Re: [PATCH 2/4] 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: <48C9A8D3.60408@gmail.com>
Date:	Fri, 12 Sep 2008 01:25:07 +0200
From:	Tejun Heo <htejun@...il.com>
To:	Valdis.Kletnieks@...edu
CC:	Elias Oltmanns <eo@...ensachen.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] libata: Implement disk shock protection support

Valdis.Kletnieks@...edu wrote:
> On Thu, 11 Sep 2008 15:01:00 +0200, Tejun Heo said:
>> Ah.. just one more thing.
>>
>> I think it would be easier on the application if the written timeout
>> value is cropped if it's over the maximum instead of failing the
>> write.
> 
> Which is better, failing the write so the application *knows* there is a
> problem, or letting the application proceed with a totally incorrect idea of
> what the value is set to?

It depends.  As -EINVAL either results in program failure or no
protection for the event.

> For instance, what happens if the program tries to set 100, it's silently
> clamped to 10, and it then tries to set a timer for itself to '90% of the
> value'?  It might be in for an unpleasant surprise when it finds out that
> it's overshot by 81....

Hitting the limit would be a pretty rare occasion and which way we go
it's not gonna be too pretty.  e.g. Let's say a program calculates
timeout according to some algorithm which 99.9% of the time stays in
the limit but once in the blue moon hits the ceiling.  Given the
characteristics of the problem and very high limit value, I think it's
better to have cropped value.

How about returning -OVERFLOW while still setting the timeout to the
maximum?

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/