On Friday 10 August 2007, Sergei Shtylyov wrote:
> Alan Cox wrote:
>
> >>>>+ if (chip_type == HPT374 && (PCI_FUNC(dev->devfn) & 1)) {
> >>>>+ struct pci_dev *dev1 = pci_get_slot(dev->bus,
> >>>>+ dev->devfn - 1);
>
> >>>Can be NULL
>
> >> Not really. This may not be called if it's NULL -- see hpt374_init_setup().
> >>Maybe worth a comment though...
>
> >>>>+ unsigned long io_base = pci_resource_start(dev1, 4);
> >>
> >>>Kaboom
> >>
> >> That was a dud bomb. ;-)
>
> > What stops a hot unplug of a 374 from causing that to occur. I don't see
>
> Pinned as in pci_get_device()? If so, see setup-ide.c:ide_scan_pcibus().
> The IDE core does that for me.
ide_scan_pcibus() is used iff IDE is built-in.
Moreover pci_get_device() holds reference _only_ to the current PCI device
(the reference count to @from PCI device is _always_ decremented).
> > where you have the other pci_dev pinned on a hotplug on a box set to scan
> > the devices in reverse order
>
> Function 1 will always be skipped, regardless of the scan order.
Yes, but init_chipset_hpt366() will still try to access Function 1
even if earlier init_setup_hpt374() failed to obtain reference to it.
> > (yes its an extremely obscure case ;))
>
> "Security through obscurity". :-)
Not in this case. :-)
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
