linux-kernel - Re: [PATCH 1/2] pci: add misrouted interrupt error handling

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: <200808051353.52323.jbarnes@virtuousgeek.org>
Date:	Tue, 5 Aug 2008 13:53:52 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH 1/2] pci: add misrouted interrupt error handling

On Tuesday, August 05, 2008 1:44 pm James Bottomley wrote:
> On Tue, 2008-08-05 at 10:03 -0700, Jesse Barnes wrote:
> > This seems to be a function that just returns what type of IRQ you're
> > using or how it's routed and it isn't necessarily "lost interrupt"
> > specific.
>
> So perhaps this routine should only note but not advise?  The drivers
> can then just call pci_interrupt_type to see if they can do anything.

If it's just a pci_irq_type function then it probably shouldn't print 
anything, and leave that to the caller, since it might be used for other 
purposes too (e.g. a driver load printk or something).  In the lost interrupt 
case you already have to disable MSI or MSIX in the Fusion driver, so you may 
as well put the printk there, right?  I guess I'm saying it should neither 
note nor advise, just return the IRQ type.

> > This information is clearly useful to drivers both for informational
> > purposes and for debugging problems, so on that front it looks good. 
> > However, I think it should probably be called pci_interrupt_type(struct
> > pci_dev *dev) or something instead, and just return an enum of either
> > MSIX, MSI, or LINE (though I'm open to better names).  From that, the
> > driver can infer what might be going wrong, though in the case of a LINE
> > interrupt, all you can really do is report that there's probably a
> > platform IRQ routing problem.
>
> The only thing that this can't do is ACPI ... but on the other hand once
> the IRQ routing is set by ACPI I'm not sure the driver can do anything
> to fix it.

Yeah, ACPI may or may not be the problem, all you'll really know is that 
you've got a line interrupt that you failed to get...  The driver won't be 
able to do much in that case aside from complain loudly.

Thanks,
Jesse
--
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/