Eric W. Biederman wrote:
> Segher Boessenkool <[EMAIL PROTECTED]> 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
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
