linux-kernel - Re: [2.6.18-rc2-mm1] libata ate one PATA channel

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: <1154371972.7230.95.camel@localhost.localdomain>
Date:	Mon, 31 Jul 2006 19:52:52 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Tejun Heo <htejun@...il.com>
Cc:	"J.A. Magall?n" <jamagallon@....com>,
	"Linux-Kernel," <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, Jeff Garzik <jgarzik@...ox.com>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [2.6.18-rc2-mm1] libata ate one PATA channel

Ar Maw, 2006-08-01 am 02:03 +0900, ysgrifennodd Tejun Heo:
> Alan, the reason why the second port disappeared is a bug in 
> init_legacy_mode().  probe_ent->n_ports is fxied to 1 and port_no gets 
> incremented while initializing the second port ending up initializing 
> part of the third port.

Ouch yes.

> Another problem is that probe_ent/ap->hard_port_no are meaningless. 
> hard_port_no is used to get port_no right on legacy cases where index of 
> host_set->ports[] doesn't match the actual port_no.  When there is only 
> one host_set, port_no should always equal hard_port_no.  For legacy 
> hosts, the original code ended up assigning the wrong hard_port_no's.

Agreed. I looked at that but it seemed that it isn't true that you can
assume port_no == hard_port_no because you may have a device which has
the primary port disabled and the secondary port set legacy. This also
sort of comes up in mixed devices but we don't handle them and I think
it comes out correctly once we do the pure legacy case right.

> I killed hard_port_no by s/ap->hard_port_no/ap->port_no/g without 
> actually reviewing the usages (man, those are a LOT).  If all pata 
> drivers always relied on ap->hard_port_no representing the actual port 
> index in the controller, there shouldn't be a problem.  But, just in 
> case, please review the change.

Think about the following execution sequence

ati_pci_init_one
	primary port already stolen by drivers/ide 
	secondary port free

	legacy_mode = ATA_PORT_SECONDARY
	ata_pci_init_legacy_port

	port_num = 0
	hard_port_num = 1

	*kerunnccchhhhhh*


> If this fixes Magallon's problem and you agree with the fix, I'll break 
> it down to two patches and submit'em to you with proper heading and all.

I agree with the theory and the diagnosis. I'm a bit worried about
hard_port_no however and I don't think that bit is safe in the secondary
only corner case. Registering both always and disabling one works for me
as a cleanup.

If you do that then I'll audit all the drivers use of ->port_no against
the patches.

Alan

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