linux-kernel - Re: Linux 2.6.25-rc4

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:	Sun, 16 Mar 2008 14:06:22 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Anders Eriksson <aeriksson@...tmail.fm>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jens Axboe <jens.axboe@...cle.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.25-rc4

On Sun, 16 Mar 2008, Alan Cox wrote:
>
> > A _lot_ of chips require you to clear the DRQ by taking the data they 
> > have.
> 
> Almost none and mostly very old ones.

Well, I admittedly haven't been involved in IDE in about a decade, so 
yeah, maybe it's simply no longer true. That said, if the second bisection 
was accurate (which is admittedly a rasonably big "if"), it really looks 
like it would be related to the fact that we used to empty the data buffer 
before handling errors for REQ_TYPE_ATA_CMD commands.

> Not in my experience having maintained a lot of ATA drivers for a very
> long time. In fact the changes for draining the DRQ went into libata only
> very recently because it was only when we had a distro sized userbase
> with PATA devices that it became apparent that a few corner case problems
> remained.

.. but as you noticed, it's almost never wrong to drain (the only chipset 
it's marked for is some broken pdc202xx one), and it definitely *is* wrong 
not to drain.

Also, one reason you'd not necessarily even see this is that with DMA, 
this is a non-issue (since the hardware DMA engine will be doing all the 
draining), so in order to ever see this you have to still use PIO _and_ 
you have to see IDE command errors in the first place _and_ you have to 
have a device that actually keeps DRQ enabled even at an error.

All of which are hopefully fairly rare by now (and getting rarer, at last 
for the PIO one).

I also wouldn't be entirely surprised if the DRQ behavior may even be 
command-specific, with the regular data path for read/write quite possibly 
being different from the special commands that go through some internal 
drive firmware logic paths.

So I could well imagine (for example) that when a drive raises an IO error 
due to a read or write fault, the DRQ line will be cleared by the drive, 
but that special commands might have some firmware-directed separate FIFO 
that needs draining.

				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/