On Wed, Dec 21, 2022 at 05:31:59PM +0900, Damien Le Moal wrote: > > > > What about the interrupt handler such as ahci_error_intr()? I didn't see > > the callers hold the port lock too. Do they need the port lock? > > It looks like it is missing for ahci_thunderx_irq_handler() but that one > takes the host lock. Same for xgene_ahci_irq_intr(), again no port lock > but host lock taken. And again for ahci_single_level_irq_intr() for the > non MSI case. For modern MSI adapters, the port lock is taken in > > For other cases, ahci_multi_irqs_intr_hard) takes the port lock. > > So it looks like ahci_port_intr() needs to take the lock and some > cleanups overall (the host lock should not be necessary in the command > path. But nobody seems to have issues with the "bad" cases... Probably > because they are not mainstream adapters. > > Definitely some work needed here. ahci_multi_irqs_intr_hard() takes the ap->lock before calling ahci_handle_port_interrupt(), which calls ahci_port_intr(), so I don't think there is any work needed for multi IRQ AHCI. For ahci_single_level_irq_intr() the host lock is taken before calling ahci_handle_port_intr(), so I don't see why we need any extra work for single IRQ AHCI. Remember, while the default is that: ap->lock = &host->lock; see: https://github.com/torvalds/linux/blob/v6.1/drivers/ata/libata-core.c#L5305 In case of MULTI MSI, the ap->lock is using its own lock: https://github.com/torvalds/linux/blob/v6.1/drivers/ata/libahci.c#L2460 So what is it that needs to be fixed for AHCI? I haven't looked at ahci_thunderx_irq_handler() and xgene_ahci_irq_intr() so I can't speak for these. Kind regards, Niklas
