linux-kernel - Re: Linux v2.6.22-rc3

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]

Date:	Sat, 02 Jun 2007 16:50:42 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Jeff Garzik <jgarzik@...ox.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Gregor Jasny <gjasny@...glemail.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux v2.6.22-rc3

Hello, Jeff, Linus.

Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Fri, 1 Jun 2007, Jeff Garzik wrote:
>>> With these old PATA devices, device reset is "six of one, half-dozen
>>> of the
>>> other."  Using SRST is the only way to kick some ATAPI devices into
>>> working:
>>> http://suif.stanford.edu/~csapuntz/blackmagic.html#reset
>>
>> Well, wouldn't it be a good thing to
>>  1) if BUSY/DRQ is set even before you try the problem, obviously skip
>> the     two polite cases, and go to #4
>>  2) try to just do an IDENTIFY  3) if that doesn't work, do a HOST
>> RESET and then try again
>>  4) if that doesn't work, do the full SRST
>>
>> (or some variation of the above).
> 
> Skipping reset means it doesn't get the device away from a state that
> the previous boot may have configured itself to... standard "I didn't do
> reset" problems you see with any hardware.  Transfer modes and
> removeable media status notification are the most notable that are left
> in a semi-random state, but there are many other minor feature bits that
> fall into this category as well.

libata configures most of the stuff, so I don't think we'll see big
surprises even if we skip SRST during probing but I agree that it's nice
to give good kicks in the devices' asses during probing.

We can try IDENTIFY/IDENTIFY_PACKET with short timeout first and then
issue reset if the device isn't in reset blacklist, but it would make
probe sequence....

 IDENTIFY -> reset -> IDENTIFY -> configure -> IDENTIFY for reval

Which doesn't seem too attractive.  We can use the result from the first
IDENTIFY for configuration but it's probably a good idea to re-read
IDENTIFY page after reset.

It would be best if we can handle these braindead SRST-impaired devices
in the common code, if that's not feasible, we should at least provide
some option to allow correct (without timeout) detection of these devices.

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/