linux-kernel - Re: Off-by-one in both LIBATA and IDE drivers

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, 14 Mar 2009 18:34:23 +0900
From:	"Norman Diamond" <n0diamond@...oo.co.jp>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Robert Hancock" <hancockrwd@...il.com>
Cc:	<linux-kernel@...r.kernel.org>, <linux-ide@...r.kernel.org>,
	"Jim Paris" <jim@...n.com>,
	"Sergei Shtylyov" <sshtylyov@...mvista.com>,
	"Bartlomiej Zolnierkiewicz" <bzolnier@...il.com>,
	"Mark Lord" <liml@....ca>
Subject: Re: Off-by-one in both LIBATA and IDE drivers

Alan Cox wrote:
> [attribution stolen:]
>> ata_piix should definitely attach to 8086/7111 regardless of the 
>> subsystem IDs. I can't really explain why it's not. You should at least 
>> be seeing a message about the ata_piix version, if not then somehow the 
>> driver probe function isn't even being called..
>
> Because on at least some kernels
> hda=noprobe ... etc
> does not stop the old IDE layer grabbing the PCI device and continuing to 
> claim ownership (which means ATA cannot attach to it).

That could be part of the explanation.  dmesg did include the usual 
statements about PIIX4 not being 100% native and irqs would be probed later 
(though of course they weren't probed later).

> Arguably this is correct behaviour as the IDE layer was asked to ignore 
> the devices *NOT* to ignore the controller.

That doesn't explain why ide0=noprobe ide1=noprobe hda=none hdb=none 
hdc=none hdd=none still didn't stop the old IDE layer from grabbing 
something.  ATA didn't report whether there was something it couldn't grab 
onto, all it did was report loading and that was the end of it.

Alan Cox also wrote:
> [Norman Diamond:]
>> I think the PIIX4 devices of VMware server are well known.  Besides 
>> vendor 8086 and device 7111, VMware's subsystem is coded into LIBATA's 
>> PIIX driver.
>
> That is a known working case so its something about your setup or build.

I doubt it.  I think your other message explained part of the reason, though 
something is still missing.

> You might want to try building with CONFIG_IDE=n and CONFIG_ATA + ATA_PIIX 
> + AHCI = y to double check your config.

CONFIG_ATA + ATA_PIIX + AHCI  were always y all along.  An experiment 
changing old IDE from y to m got PIIX4 working, but I'm still nervous about 
lots of cases where I don't have machines with other old IDE chipsets to 
test. 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--
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/