In case of a new tt_local_entry, the TT_CLIENT_NEW flag has to be set before adding such entry to the hash table. Otherwise, a concurrent a tt_query_reply forging operation could select such entry (as it is already in the hash table) even if it should not.
Signed-off-by: Antonio Quartulli ordex@autistici.org --- translation-table.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/translation-table.c b/translation-table.c index 7ea4c42..b493ab4 100644 --- a/translation-table.c +++ b/translation-table.c @@ -210,6 +210,11 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr, if (compare_eth(addr, soft_iface->dev_addr)) tt_local_entry->common.flags |= TT_CLIENT_NOPURGE;
+ /* The local entry has to be marked as NEW to avoid to send it in + * a full table response going out before the next ttvn increment + * (consistency check) */ + tt_local_entry->common.flags |= TT_CLIENT_NEW; + hash_added = hash_add(bat_priv->tt_local_hash, compare_tt, choose_orig, &tt_local_entry->common, &tt_local_entry->common.hash_entry); @@ -222,11 +227,6 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr,
tt_local_event(bat_priv, addr, tt_local_entry->common.flags);
- /* The local entry has to be marked as NEW to avoid to send it in - * a full table response going out before the next ttvn increment - * (consistency check) */ - tt_local_entry->common.flags |= TT_CLIENT_NEW; - /* remove address from global hash if present */ tt_global_entry = tt_global_hash_find(bat_priv, addr);
Each tt_local_set_pending is always followed by a bat_dbg invocation. This patch moves the latter into the function body in order to avoid to rewrite it all the times.
Signed-off-by: Antonio Quartulli ordex@autistici.org --- translation-table.c | 15 ++++++--------- 1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/translation-table.c b/translation-table.c index b493ab4..d105cbd 100644 --- a/translation-table.c +++ b/translation-table.c @@ -355,7 +355,7 @@ out:
static void tt_local_set_pending(struct bat_priv *bat_priv, struct tt_local_entry *tt_local_entry, - uint16_t flags) + uint16_t flags, const char *message) { tt_local_event(bat_priv, tt_local_entry->common.addr, tt_local_entry->common.flags | flags); @@ -364,6 +364,9 @@ static void tt_local_set_pending(struct bat_priv *bat_priv, * to be kept in the table in order to send it in a full table * response issued before the net ttvn increment (consistency check) */ tt_local_entry->common.flags |= TT_CLIENT_PENDING; + + bat_dbg(DBG_TT, bat_priv, "Local tt entry (%pM) pending to be removed: " + "%s\n", tt_local_entry->common.addr, message); }
void tt_local_remove(struct bat_priv *bat_priv, const uint8_t *addr, @@ -376,10 +379,7 @@ void tt_local_remove(struct bat_priv *bat_priv, const uint8_t *addr, goto out;
tt_local_set_pending(bat_priv, tt_local_entry, TT_CLIENT_DEL | - (roaming ? TT_CLIENT_ROAM : NO_FLAGS)); - - bat_dbg(DBG_TT, bat_priv, "Local tt entry (%pM) pending to be removed: " - "%s\n", tt_local_entry->common.addr, message); + (roaming ? TT_CLIENT_ROAM : NO_FLAGS), message); out: if (tt_local_entry) tt_local_entry_free_ref(tt_local_entry); @@ -417,10 +417,7 @@ static void tt_local_purge(struct bat_priv *bat_priv) continue;
tt_local_set_pending(bat_priv, tt_local_entry, - TT_CLIENT_DEL); - bat_dbg(DBG_TT, bat_priv, "Local tt entry (%pM) " - "pending to be removed: timed out\n", - tt_local_entry->common.addr); + TT_CLIENT_DEL, "timed out"); } spin_unlock_bh(list_lock); }
On Saturday, January 07, 2012 04:31:34 Antonio Quartulli wrote:
Each tt_local_set_pending is always followed by a bat_dbg invocation. This patch moves the latter into the function body in order to avoid to rewrite it all the times.
Applied in revision 4ead48d.
Thanks, Marek
On Saturday, January 07, 2012 04:31:33 Antonio Quartulli wrote:
In case of a new tt_local_entry, the TT_CLIENT_NEW flag has to be set before adding such entry to the hash table. Otherwise, a concurrent a tt_query_reply forging operation could select such entry (as it is already in the hash table) even if it should not.
Applied in revision 5c5fa22.
Thanks, Marek
b.a.t.m.a.n@lists.open-mesh.org