[openib-general] [PATCH 5/6] Use pci_find_ht_capability() in drivers/pci/quirks.c

[Brice Goglin]

Eric W. Biederman wrote:
> Segher Boessenkool <segher at kernel.crashing.org> writes:
>
>   
>>> What if we didn't try to solve a problem we don't have ?
>>>       
>> Yes exactly.
>>
>>     
>>> Have we yet encountered an HT device with that sort of bogus  capability
>>> list ?
>>>       
>> Nope.  So whatever fancy time-to-live scheme we come
>> up with, we cannot even test it, and it performance
>> no useful function.  Nuke it :-)
>>     
>
> If we really need to we can put a loop detector in pci_find_capability
> by looking ahead a little.  So we really should not even need to change
> the API to do this.
>
> So nuke it and if it is important have pci_find_capability bail if
> there are loops in the capability chain.
>
> Eric
>   

How do you want to detect the following loop in pci_find_capability()
without changing the API?
    any cap -> any cap -> one HT cap -> any cap -> back to first HT cap
When looking for a HT cap, pci_find_capability() will always succeed, it
will never loop forever. But, pci_find_ht_capability() will loop forever
if it is looking for a different HT cap than the one we have in the chain.

When we add a new function looping on top of the existing functions, we
can always find a brain-damaged chain which makes the new function loop
forever while the existing ones do not... That's why I had a new TTL in
msi_ht_cap_enabled() in drivers/pci/quirks.c even if I was using
pci_find_next_capability() which has its own TTL.

Anyway, I agree that protecting against bugs that we've never seen
before is not that important. I was just thinking that protecting is
very easy, while debugging might be boring once we find such a broken
PCI chain :)

Brice