summaryrefslogtreecommitdiffstats
path: root/drivers/pci/vpd.c
diff options
context:
space:
mode:
authorAntonio Quartulli <ordex@autistici.org>2012-06-20 14:12:56 +0200
committerAntonio Quartulli <ordex@autistici.org>2012-06-23 17:21:35 +0200
commit8b8e4bc0391f8abbcdb9e1c54415bcc0f4f5a2a0 (patch)
treebd8c2e47bb0cbc05e1ec5f79f8fd3f6410463d5b /drivers/pci/vpd.c
parent5870adc68fc39d81089f1e80efdf64b97e5c37a1 (diff)
batman-adv: fix race condition in TT full-table replacement
bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a In the current TT code, when a TT_Response containing a full table is received from an originator, first the node purges all the clients for that originator in the global translation-table and then merges the newly received table. During the purging phase each client deletion is done by means of a call_rcu() invocation and at the end of this phase the global entry counter for that originator is set to 0. However the invoked rcu function decreases the global entry counter for that originator by one too and since the rcu invocation is likely to be postponed, the node will end up in first setting the counter to 0 and then decreasing it one by one for each deleted client. This bug leads to having a wrong global entry counter for the related node, say X. Then when the node with the broken counter will answer to a TT_REQUEST on behalf of node X, it will create faulty TT_RESPONSE that will generate an unrecoverable situation on the node that asked for the full table recover. The non-recoverability is given by the fact that the node with the broken counter will keep answering on behalf of X because its knowledge about X's state (ttvn + tt_crc) is correct. To solve this problem the counter is not explicitly set to 0 anymore and the counter decrement is performed right before the invocation of call_rcu(). Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Diffstat (limited to 'drivers/pci/vpd.c')
0 files changed, 0 insertions, 0 deletions