On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote: > > What about introducing pci_lock_msi() and pci_unlock_msi() and let device > > drivers care about their ranges and specifics in race-safe manner? > > I do not call to introduce it right now (since it appears pSeries has not > > been hitting the race for years) just as a possible alternative to Ben's > > proposal. > > I don't think the same race condition would happen with the loop. We need to distinguish the contexts we're discussing. If we talk about pSeries quota, then the current pSeries pci_enable_msix() implementation is racy internally and could fail if the quota went down *while* pci_enable_msix() is executing. In this case the loop will have to exit rather than retry with a lower number (what number?). In this regard the new scheme does not bring anything new and relies on the fact this race does not hit and therefore does not worry. If we talk about quota as it has to be, then yes - the loop scheme seems more preferable. Overall, looks like we just need to fix the pSeries implementation, if the guys want it, he-he :) > The problem case is where multiple msi(x) allocation fails completely > because the global limit went down before inquiry and allocation. In > the loop based interface, it'd retry with the lower number. I am probably missing something here. If the global limit went down before inquiry then the inquiry will get what is available and try to allocate with than number. -- Regards, Alexander Gordeev agordeev@xxxxxxxxxx -- 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
