On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote: > On 13-09-18 05:48 AM, Alexander Gordeev wrote: > > > > The last pattern makes most of sense to me and could be updated with a more > > clear sequence - a call to (bit modified) pci_msix_table_size() followed > > by a call to pci_enable_msix(). I think this pattern can effectively > > supersede the currently recommended "loop" practice. > > The loop is still necessary, because there's a race between those two calls, > so that pci_enable_msix() can still fail due to lack of MSIX slots. Hi Mark, Can you elaborate on this race? My understanding is that pci_msix_table_size() depends only on the "Table Size" field in the MSI-X Message Control register. So if there's a concurrency problem here, it would have to be something like "pci_enable_msix() may not be able to configure the requested number of vectors because it has to allocate from a shared pool." If that's the case, pci_msix_table_size() wouldn't be involved at all, and the only question is how to coordinate between several drivers that each call pci_enable_msix(). I think that would have to be resolved in some arch hook used by the PCI core. Maybe this is already taken care of; I just want to make sure we don't overlook an issue here. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
