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, 8 Nov 2008 00:57:30 -0700
From:	Grant Grundler <grundler@...isc-linux.org>
To:	Nobin Mathew <nobin.mathew@...il.com>
Cc:	Jiri Slaby <jirislaby@...il.com>, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, Robert Hancock <hancockr@...w.ca>
Subject: Re: sharing interrupt between PCI device

On Wed, Nov 05, 2008 at 02:50:01PM +0530, Nobin Mathew wrote:
> Hi
> 
> 
> Code is here
> first one USB Virual input devices
> 
> http://lxr.linux.no/linux+v2.6.27.4/drivers/usb/core/hcd-pci.c
> 
> Second one is hp-ilo driver
> 
> http://lxr.linux.no/linux+v2.6.27.4/drivers/misc/hpilo.c

I looked for usage of request_irq() and didn't see it in either driver.

I was looking for the parameters passed to the request_irq() call.
If the IRQ and the "dev_id" parameter are the same for both drivers,
I'm not sure how the generic IRQ management code could tell them apart
and then might disable the wrong instance when free_irq() is called.
Perhaps you already know where the respective request_irq() calls are
and can easily determine that both are passing in a NULL for
the "dev_id" parameter?


If that's not the case, I would be looking for bugs in the generic
shared IRQ code.  But given shared IRQ experience with older kernels,
I'm not inclined to believe there is a problem in the generic IRQ code
on newer kernels unless presented with contrary evidence.

hth,
grant



> 
> Thanks
> Nobin Mathew.
> 
> 
> On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby <jirislaby@...il.com> wrote:
> > On 11/05/2008 08:49 AM, Nobin Mathew wrote:
> >> Hi
> >>
> >> This is the system information X86_64 platform Xeon dual core processor.
> >>
> >> I saw the pci_disable_device () it is calling pcibios_disable_device
> >> () and this is is defined as
> >>
> >> void pcibios_disable_device (struct pci_dev *dev)
> >> {
> >>         pcibios_disable_resources(dev);
> >>         if (pcibios_disable_irq)
> >>                 pcibios_disable_irq(dev);
> >> }
> >>
> >> In i386 platform, I could not find a definition for these calls in
> >> x86_64 platform, i think it is using i386 platform code.
> >
> > Well, will you show us the code, so that we needn't to crystal gaze? It's pretty
> > hard to say what happens, if we don't see what you do in the driver...
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/

Powered by blists - more mailing lists