linux-kernel - Re: Slow tape drive timeout

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

Date:	Fri, 04 Apr 2008 11:37:20 +0200
From:	Bodo Eggert <7eggert@....de>
To:	Kai Makisara <Kai.Makisara@...umbus.fi>,
	Robert Hancock <hancockr@...w.ca>,
	Carlo Nyto <carlonyto@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Slow tape drive timeout

Kai Makisara <Kai.Makisara@...umbus.fi> wrote:
> On Wed, 2 Apr 2008, Robert Hancock wrote:

>> Why is accessing the tape drive with no tape in it causing a timeout in the
>> first place? I should think that would fail immediately with some "medium not
>> present" error from the drive. Unless the drive has no mechanism to detect
>> it, but that seems really retarded..
>> 
> It does not seem retarded to me. If a program wants to just wait until the
> tape drive becomes ready (e.g., loads the tape), it can use the blocking
> open. This is simple.

This would be simple, if there were no timeout. Having the timeout, the program
must loop anyway.

> If a program wants to test the status, it uses 
> non-blocking open. The behavior mandated by the standards provides
> alternatives. If O_NONBLOCK is not supported, the user program must
> implement the waiting logic if the program just wants to wait until the
> drive is ready before starting i/o.

Therfore a portable program SHOULD implement a waiting logic that won't burn
the CPU if there is no tape in the drive.

It's still sane to allow waiting for media change, but this applies to any
removable media.

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