linux-kernel - Re: PCI device driver broken between 4.2 and 4.3

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20160205174035.GB24785@localhost>
Date:	Fri, 5 Feb 2016 11:40:35 -0600
From:	Bjorn Helgaas <helgaas@...nel.org>
To:	Олег Мороз <oleg.moroz@....vniiem.ru>
Cc:	linux-pci@...r.kernel.org, Jiang Liu <jiang.liu@...ux.intel.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Sunjin Yang <fan4326@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: PCI device driver broken between 4.2 and 4.3

[+cc Jiang, Yinghai, Sunjin, linux-kernel]

On Sat, Jan 23, 2016 at 10:08:50AM +0300, Олег Мороз wrote:
> Hello. I've got a device driver for MIL-1553b card called TA1-PCI,
> which could be found at
> https://github.com/qmor/elcus-1553-driver-linux
> Card is using PLX_PCI9030 PCI controller.
> Today i've found that this driver compiles, installes, but is not
> working as it should.
> Looks like it not receives any interrupts from PCI. I've test it
> again with kernel
> 4.2 and it works okay. What changes was made in PCI subsystem from
> 4.2 to 4.3
> which could have impact this driver work.

Sunjin reported another driver, RocketRAID 272x, with the same
problem.  "pci=routeirq" is a workaround:
https://bugzilla.kernel.org/show_bug.cgi?id=111211#c7

Олег bisected the problem with his driver to Jiang's patch,
991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") and found that "pci=routeirq" was a workaround.

I don't think Sunjin has bisected this, but the RocketRAID driver
stopped working at the same time and the same workaround works, so we
assume it is the same problem.

Prior to 991de2e59090, we called pcibios_enable_irq() in the
pci_enable_device() path, which recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e59090, we call pcibios_enable_irq() from the
pci_device_probe() path instead of the pci_enable_device() path.  This
does *not* call pcibios_enable_irq() for upstream bridges.

I think this is what Yinghai meant in his response, but I didn't
understand the connection.

This is a pretty serious problem that should affect many devices
behind bridges, so I think we need a PCI or ACPI core fix.  Jiang?

Bjorn