Re: linux-next: pata_acpi.ko crashes at ata_ap_acpi_handle()

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

>        We can see the code in ata_ap_acpi_handle()accesses ap->scsi_host filed without checking if it’s initialized, which causes NULL pointer panic. Meanwhile, ata_pci_sff_activate_host() calls ata_host_register(), which calls ata_scsi_add_hosts() to initialize scsi_host field. Both calls are after ata_host_start() in a must-visit code path. I believe ata_scsi_add_hosts() is the first place for initialization because it does not check if scsi_host field is NULL either. So it makes no sense to access ap->scsi_host in ata_ap_acpi_handle().

This appears to be caused by broken changes to the libata code from
Matthew Garrett and others who introduced a dependancy on scsi_host which
isn't safe to do because drivers can touch the ACPI earlier than the
scsi registration and in fact *NEED* to do so.

Jeff - can we get these patches dropped back out for the moment - they
cause a regression and boot crash in pata_acpi.

The stack from 75d22cd567cac6fe2af8acb33f6ebcd16876d250 needs to get
punted and the scsi_host indirection removed and fixed up for it to work
safely with existing libata drivers.

I don't see an obvious way to fix up the existing ordering dependancies,
especially on the pata_acpi side but if someone has bright ideas there
that would probably be the best choice. Right now these patches stop any
ACPI querying being done during the port setup. We need to do those
queries in order to know if the port can be driven by ACPI and what modes
we can make work.

Alan