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:	Tue, 29 May 2007 09:44:10 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tejun Heo <htejun@...il.com>
cc:	Gregor Jasny <gjasny@...glemail.com>,
	Jeff Garzik <jgarzik@...ox.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

On Tue, 29 May 2007, Tejun Heo wrote:
> 
> Aieee, so the drive doesn't like the new SRST sequence.

It would appear that the old code largely ignored the SRST error entirely, 
no?

If we *used* to do (in ata_bus_post_reset()):

	if (dev0)
		ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);

and you changed that to actually care about the return value:

	if (dev0) {
		rc = ata_wait_ready(ap, deadline);
		if (rc && rc != -ENODEV)
			return rc;
	}

(in _two_ places). That change also changed the same "post_reset" handling 
in a totally _different_ way: it used to do ata_busy_sleep() twice, now it 
still does it twice, but it does it with the same "timeout" value, so if 
the first one times out, then the second one won't be given any timeout AT 
ALL!

And to make matters worse: the first timeout seems to be for ANOTHER PORT 
ENTIRELY! So you seem to break port 1 even if the timeout happened on port 
0, as far as I can read that sequence. 

So I think your ata_bus_post_reset() changes are rather suspect. The fact 
that you don't change the timeout, and use the same deadline for two 
different ports (and for multiple commands to the same port, afaik), seems 
rather suspect. The old code also didn't care about failures in certain 
phases of the reset sequence, and it appears that it did so for good 
reason.

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