1. 25 8月, 2015 2 次提交
  2. 15 8月, 2015 1 次提交
    • L
      batman-adv: Fix potential synchronization issues in mcast tvlv handler · 8a4023c5
      Linus Lüssing 提交于
      So far the mcast tvlv handler did not anticipate the processing of
      multiple incoming OGMs from the same originator at the same time. This
      can lead to various issues:
      
      * Broken refcounting: For instance two mcast handlers might both assume
        that an originator just got multicast capabilities and will together
        wrongly decrease mcast.num_disabled by two, potentially leading to
        an integer underflow.
      
      * Potential kernel panic on hlist_del_rcu(): Two mcast handlers might
        one after another try to do an
        hlist_del_rcu(&orig->mcast_want_all_*_node). The second one will
        cause memory corruption / crashes.
        (Reported by: Sven Eckelmann <sven@narfation.org>)
      
      Right in the beginning the code path makes assumptions about the current
      multicast related state of an originator and bases all updates on that. The
      easiest and least error prune way to fix the issues in this case is to
      serialize multiple mcast handler invocations with a spinlock.
      
      Fixes: 60432d75 ("batman-adv: Announce new capability via multicast TVLV")
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>
      8a4023c5
  3. 07 6月, 2015 2 次提交
    • S
      batman-adv: Add required includes to all files · 1e2c2a4f
      Sven Eckelmann 提交于
      The header files could not be build indepdent from each other. This is
      happened because headers didn't include the files for things they've used.
      This was problematic because the success of a build depended on the
      knowledge about the right order of local includes.
      
      Also source files were not including everything they've used explicitly.
      Instead they required that transitive includes are always stable. This is
      problematic because some transitive includes are not obvious, depend on
      config settings and may not be stable in the future.
      
      The order for include blocks are:
      
       * primary headers (main.h and the *.h file of a *.c file)
       * global linux headers
       * required local headers
       * extra forward declarations for pointers in function/struct declarations
      
      The only exceptions are linux/bitops.h and linux/if_ether.h in packet.h.
      This header file is shared with userspace applications like batctl and must
      therefore build together with userspace applications. The header
      linux/bitops.h is not part of the uapi headers and linux/if_ether.h
      conflicts with the musl implementation of netinet/if_ether.h. The
      maintainers rejected the use of __KERNEL__ preprocessor checks and thus
      these two headers are only in main.h. All files using packet.h first have
      to include main.h to work correctly.
      Reported-by: NMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      1e2c2a4f
    • A
      batman-adv: add bat_neigh_free API · bcef1f3c
      Antonio Quartulli 提交于
      This API has to be used to let any routing protocol free
      neighbor specific allocated resources
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      bcef1f3c
  4. 29 5月, 2015 1 次提交
  5. 08 1月, 2015 1 次提交
  6. 06 1月, 2015 2 次提交
    • L
      batman-adv: fix potential TT client + orig-node memory leak · 9d31b3ce
      Linus Lüssing 提交于
      This patch fixes a potential memory leak which can occur once an
      originator times out. On timeout the according global translation table
      entry might not get purged correctly. Furthermore, the non purged TT
      entry will cause its orig-node to leak, too. Which additionally can lead
      to the new multicast optimization feature not kicking in because of a
      therefore bogus counter.
      
      In detail: The batadv_tt_global_entry->orig_list holds the reference to
      the orig-node. Usually this reference is released after
      BATADV_PURGE_TIMEOUT through: _batadv_purge_orig()->
      batadv_purge_orig_node()->batadv_update_route()->_batadv_update_route()->
      batadv_tt_global_del_orig() which purges this global tt entry and
      releases the reference to the orig-node.
      
      However, if between two batadv_purge_orig_node() calls the orig-node
      timeout grew to 2*BATADV_PURGE_TIMEOUT then this call path isn't
      reached. Instead the according orig-node is removed from the
      originator hash in _batadv_purge_orig(), the batadv_update_route()
      part is skipped and won't be reached anymore.
      
      Fixing the issue by moving batadv_tt_global_del_orig() out of the rcu
      callback.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Acked-by: NAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>
      9d31b3ce
    • L
      batman-adv: fix delayed foreign originator recognition · 2c667a33
      Linus Lüssing 提交于
      Currently it can happen that the reception of an OGM from a new
      originator is not being accepted. More precisely it can happen that
      an originator struct gets allocated and initialized
      (batadv_orig_node_new()), even the TQ gets calculated and set correctly
      (batadv_iv_ogm_calc_tq()) but still the periodic orig_node purging
      thread will decide to delete it if it has a chance to jump between
      these two function calls.
      
      This is because batadv_orig_node_new() initializes the last_seen value
      to zero and its caller (batadv_iv_ogm_orig_get()) makes it visible to
      other threads by adding it to the hash table already.
      batadv_iv_ogm_calc_tq() will set the last_seen variable to the correct,
      current time a few lines later but if the purging thread jumps in between
      that it will think that the orig_node timed out and will wrongly
      schedule it for deletion already.
      
      If the purging interval is the same as the originator interval (which is
      the default: 1 second), then this game can continue for several rounds
      until the random OGM jitter added enough difference between these
      two (in tests, two to about four rounds seemed common).
      
      Fixing this by initializing the last_seen variable of an orig_node
      to the current time before adding it to the hash table.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>
      2c667a33
  7. 16 5月, 2014 1 次提交
  8. 11 5月, 2014 1 次提交
  9. 10 5月, 2014 2 次提交
  10. 22 3月, 2014 3 次提交
  11. 18 2月, 2014 1 次提交
  12. 12 1月, 2014 6 次提交
  13. 09 1月, 2014 1 次提交
  14. 27 12月, 2013 1 次提交
  15. 23 10月, 2013 5 次提交
  16. 20 10月, 2013 2 次提交
    • A
      batman-adv: make the TT global purge routine VLAN specific · 95fb130d
      Antonio Quartulli 提交于
      Instead of unconditionally removing all the TT entries
      served by a given originator, make tt_global_orig_del()
      remove only entries matching a given VLAN identifier
      provided as argument.
      
      If such argument is negative all the global entries
      served by the originator are removed.
      
      This change is used into the BLA code to purge entries
      served by a newly discovered Backbone node, but limiting
      the operation only to those connected to the VLAN where the
      backbone has been discovered.
      
      Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>
      95fb130d
    • A
      batman-adv: make the TT CRC logic VLAN specific · 7ea7b4a1
      Antonio Quartulli 提交于
      This change allows nodes to handle the TT table on a
      per-VLAN basis. This is needed because nodes may have to
      store only some of the global entries advertised by another
      node.
      
      In this scenario such nodes would re-create only a partial
      global table and would not be able to compute a correct CRC
      anymore.
      
      This patch splits the logic and introduces one CRC per VLAN.
      In this way a node fetching only some entries belonging to
      some VLANs is still able to compute the needed CRCs and
      still check the table correctness.
      
      With this patch the shape of the TVLV-TT is changed too
      because now a node needs to advertise all the CRCs of all
      the VLANs that it is wired to.
      
      The debug output of the local Translation Table now shows
      the CRC along with each entry since there is not a common
      value for the entire table anymore.
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>
      7ea7b4a1
  17. 19 10月, 2013 1 次提交
    • A
      batman-adv: lock around TT operations to avoid sending inconsistent data · a70a9aa9
      Antonio Quartulli 提交于
      A TT response may be prepared and sent while the local or
      global translation table is getting updated.
      
      The worst case is when one of the tables is accessed after
      its content has been recently updated but the metadata
      (TTVN/CRC) has not yet. In this case the reader will get a
      table content which does not match the TTVN/CRC.
      This will lead to an inconsistent state and so to a TT
      recovery.
      
      To avoid entering this situation, put a lock around those TT
      operations recomputing the metadata and around the TT
      Response creation (the latter is the only reader that
      accesses the metadata together with the table).
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>
      a70a9aa9
  18. 12 10月, 2013 2 次提交
  19. 10 10月, 2013 1 次提交
  20. 29 5月, 2013 2 次提交
  21. 17 5月, 2013 1 次提交
  22. 27 3月, 2013 1 次提交