linux-kernel - Re: 2.6.23-mm1

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: <47110500.8050503@garzik.org>
Date:	Sat, 13 Oct 2007 13:48:48 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Torsten Kaiser <just.for.lkml@...glemail.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Kuan Luo <kluo@...dia.com>, Peer Chen <pchen@...dia.com>
Subject: Re: 2.6.23-mm1

Torsten Kaiser wrote:
> On 10/13/07, Torsten Kaiser <just.for.lkml@...glemail.com> wrote:
>> Wait!
>>
>> I think I found the bug: Its a evil interaction between the above
>> patch and the swncq patch that is applied later.
>> The qc_defer patch removes the old ata_scmd_need_defer that was always
>> called for all drivers and substitutes it for ata_std_qc_defer and
>> adds it as aops->qc_defer to all drivers that support NCQ *at that
>> point*.
>> Then the swncq patch adds a new NCQ capable driver, but the nobody
>> added the qc_defer-ops to the ops-structure that is added. So swncq
>> will never defer any commands and the first command that would need to
>> be defered (the SMART commands) blows up, if there is still another
>> command in flight.
>>
>> I will only add the qc_defer and try this...
> 
> 3 boots, all worked. So I'm very sure that was the bug, but I will now
> do a little load testing...
> 
> The only strange thing about 2.6.23-mm1 is, that it takes ~4 second
> more to boot.

So, you basically applied the attached patch?

Yeah, absence of qc_defer for an NCQ-capable chip would do it.

	Jeff



View attachment "patch" of type "text/plain" (458 bytes)