1. 13 1月, 2015 22 次提交
  2. 09 1月, 2015 1 次提交
    • Y
      tipc: convert tipc reference table to use generic rhashtable · 07f6c4bc
      Ying Xue 提交于
      As tipc reference table is statically allocated, its memory size
      requested on stack initialization stage is quite big even if the
      maximum port number is just restricted to 8191 currently, however,
      the number already becomes insufficient in practice. But if the
      maximum ports is allowed to its theory value - 2^32, its consumed
      memory size will reach a ridiculously unacceptable value. Apart from
      this, heavy tipc users spend a considerable amount of time in
      tipc_sk_get() due to the read-lock on ref_table_lock.
      
      If tipc reference table is converted with generic rhashtable, above
      mentioned both disadvantages would be resolved respectively: making
      use of the new resizable hash table can avoid locking on the lookup;
      smaller memory size is required at initial stage, for example, 256
      hash bucket slots are requested at the beginning phase instead of
      allocating the entire 8191 slots in old mode. The hash table will
      grow if entries exceeds 75% of table size up to a total table size
      of 1M, and it will automatically shrink if usage falls below 30%,
      but the minimum table size is allowed down to 256.
      
      Also converts ref_table_lock to a separate mutex to protect hash table
      mutations on write side. Lastly defers the release of the socket
      reference using call_rcu() to allow using an RCU read-side protected
      call to rhashtable_lookup().
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Acked-by: NErik Hugne <erik.hugne@ericsson.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07f6c4bc
  3. 08 1月, 2015 15 次提交
  4. 07 1月, 2015 1 次提交
  5. 06 1月, 2015 1 次提交
    • 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