linux-kernel - Re: ATA device reset, shoud I be concerned?

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: <20080121164744.2f7d0ed1@lxorguk.ukuu.org.uk>
Date:	Mon, 21 Jan 2008 16:47:44 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Tejun Heo <htejun@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Georgi Chulkov <g.chulkov@...obs-university.de>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Mark Lord <liml@....ca>
Subject: Re: ATA device reset, shoud I be concerned?

> Can you elaborate a bit?  I don't really think completing a command
> after 30sec timeout contributes a lot to driver stability.

Timeout, timeout, timeout, reset, timeout.. (repeat), failed I/O

This gives the end user no information about the fault, nor does it let
the upper layers of SCSI and above distinguish between a random passing
sulk and media errors which need the disk replacing.

> > Should that not then be a per host flag ?
> 
> Yeah, that would be the best.  The problem is that there are several
> different kinds of timeouts and we don't know which controller locks up
> after which timeout and investigating them is really difficult.

PATA controllers don't lock up in that case so its quite easy. The one
exception is if the device jams IORDY but in that case you are dead
anyway the next I/O (except on a SIL680 which has a timer we could use).

Old IDE says it works for PATA. For SATA I can see it might need more
care and you might simply not be able to get the info.

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