1. 25 6月, 2012 4 次提交
  2. 21 6月, 2012 6 次提交
  3. 19 6月, 2012 2 次提交
  4. 18 4月, 2012 1 次提交
  5. 17 2月, 2012 3 次提交
  6. 20 11月, 2011 2 次提交
    • A
      batman-adv: create a common substructure for tt_global/local_entry · 48100bac
      Antonio Quartulli 提交于
      Several functions in the translation table management code assume that the
      tt_global_entry and tt_local_entry structures have the same initial fields such
      as 'addr' and 'hash_entry'. To improve the code readability and to avoid
      mistakes in later changes, a common substructure that substitute the shared
      fields has been introduced (struct tt_common_entry).
      
      Thanks to this modification, it has also been possible to slightly reduce the
      code length by merging some functions like compare_ltt/gtt() and
      tt_local/global_hash_find()
      Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      48100bac
    • A
      batman-adv: fixed hash functions type to uint32_t instead of int · c90681b8
      Antonio Quartulli 提交于
      There are two reasons for this fix:
      - the result of choose_orig() and vis_choose() is an index and therefore it can't
        be negative. Hence it is correct to make the return type unsigned too.
      
      - sizeof(int) may not be the same on ALL the architectures. Since we plan to use
        choose_orig() as DHT hash function, we need to guarantee that, given the same
        argument, the result is the same. Then it is correct to explicitly express
        the size of the return type (and the second argument). Since the expected
        length is currently 4, uint32_t is the most convenient choice.
      Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      c90681b8
  7. 08 9月, 2011 1 次提交
  8. 22 8月, 2011 2 次提交
  9. 20 6月, 2011 1 次提交
  10. 30 5月, 2011 4 次提交
  11. 08 5月, 2011 1 次提交
  12. 02 5月, 2011 1 次提交
  13. 18 4月, 2011 1 次提交
  14. 05 3月, 2011 7 次提交
  15. 31 1月, 2011 1 次提交
  16. 30 1月, 2011 3 次提交
    • S
      batman-adv: Make vis info stack traversal threadsafe · 1181e1da
      Sven Eckelmann 提交于
      The batman-adv vis server has to a stack which stores all information
      about packets which should be send later. This stack is protected
      with a spinlock that is used to prevent concurrent write access to it.
      
      The send_vis_packets function has to take all elements from the stack
      and send them to other hosts over the primary interface. The send will
      be initiated without the lock which protects the stack.
      
      The implementation using list_for_each_entry_safe has the problem that
      it stores the next element as "safe ptr" to allow the deletion of the
      current element in the list. The list may be modified during the
      unlock/lock pair in the loop body which may make the safe pointer
      not pointing to correct next element.
      
      It is safer to remove and use the first element from the stack until no
      elements are available. This does not need reduntant information which
      would have to be validated each time the lock was removed.
      Reported-by: NRussell Senior <russell@personaltelco.net>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      1181e1da
    • S
      batman-adv: Remove vis info element in free_info · dda9fc6b
      Sven Eckelmann 提交于
      The free_info function will be called when no reference to the info
      object exists anymore. It must be ensured that the allocated memory
      gets freed and not only the elements which are managed by the info
      object.
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      dda9fc6b
    • S
      batman-adv: Remove vis info on hashing errors · 2674c158
      Sven Eckelmann 提交于
      A newly created vis info object must be removed when it couldn't be
      added to the hash. The old_info which has to be replaced was already
      removed and isn't related to the hash anymore.
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      2674c158