1. 01 5月, 2017 1 次提交
  2. 25 4月, 2017 1 次提交
  3. 22 4月, 2017 1 次提交
    • W
      net_sched: move the empty tp check from ->destroy() to ->delete() · 763dbf63
      WANG Cong 提交于
      We could have a race condition where in ->classify() path we
      dereference tp->root and meanwhile a parallel ->destroy() makes it
      a NULL. Daniel cured this bug in commit d9363774
      ("net, sched: respect rcu grace period on cls destruction").
      
      This happens when ->destroy() is called for deleting a filter to
      check if we are the last one in tp, this tp is still linked and
      visible at that time. The root cause of this problem is the semantic
      of ->destroy(), it does two things (for non-force case):
      
      1) check if tp is empty
      2) if tp is empty we could really destroy it
      
      and its caller, if cares, needs to check its return value to see if it
      is really destroyed. Therefore we can't unlink tp unless we know it is
      empty.
      
      As suggested by Daniel, we could actually move the test logic to ->delete()
      so that we can safely unlink tp after ->delete() tells us the last one is
      just deleted and before ->destroy().
      
      Fixes: 1e052be6 ("net_sched: destroy proto tp when all filters are gone")
      Cc: Roi Dayan <roid@mellanox.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      763dbf63
  4. 14 4月, 2017 1 次提交
  5. 18 2月, 2017 2 次提交
  6. 04 2月, 2017 1 次提交
  7. 31 1月, 2017 1 次提交
  8. 20 1月, 2017 1 次提交
    • A
      net/sched: cls_flower: reduce fl_change stack size · 39b7b6a6
      Arnd Bergmann 提交于
      The new ARP support has pushed the stack size over the edge on ARM,
      as there are two large objects on the stack in this function (mask
      and tb) and both have now grown a bit more:
      
      net/sched/cls_flower.c: In function 'fl_change':
      net/sched/cls_flower.c:928:1: error: the frame size of 1072 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      We can solve this by dynamically allocating one or both of them.
      I first tried to do it just for the mask, but that only saved
      152 bytes on ARM, while this version just does it for the 'tb'
      array, bringing the stack size back down to 664 bytes.
      
      Fixes: 99d31326 ("net/sched: cls_flower: Support matching on ARP")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39b7b6a6
  9. 17 1月, 2017 1 次提交
  10. 12 1月, 2017 1 次提交
  11. 29 12月, 2016 1 次提交
  12. 24 12月, 2016 1 次提交
  13. 17 12月, 2016 2 次提交
  14. 09 12月, 2016 2 次提交
  15. 06 12月, 2016 1 次提交
  16. 03 12月, 2016 3 次提交
  17. 30 11月, 2016 1 次提交
  18. 28 11月, 2016 1 次提交
    • D
      net, sched: respect rcu grace period on cls destruction · d9363774
      Daniel Borkmann 提交于
      Roi reported a crash in flower where tp->root was NULL in ->classify()
      callbacks. Reason is that in ->destroy() tp->root is set to NULL via
      RCU_INIT_POINTER(). It's problematic for some of the classifiers, because
      this doesn't respect RCU grace period for them, and as a result, still
      outstanding readers from tc_classify() will try to blindly dereference
      a NULL tp->root.
      
      The tp->root object is strictly private to the classifier implementation
      and holds internal data the core such as tc_ctl_tfilter() doesn't know
      about. Within some classifiers, such as cls_bpf, cls_basic, etc, tp->root
      is only checked for NULL in ->get() callback, but nowhere else. This is
      misleading and seemed to be copied from old classifier code that was not
      cleaned up properly. For example, d3fa76ee ("[NET_SCHED]: cls_basic:
      fix NULL pointer dereference") moved tp->root initialization into ->init()
      routine, where before it was part of ->change(), so ->get() had to deal
      with tp->root being NULL back then, so that was indeed a valid case, after
      d3fa76ee, not really anymore. We used to set tp->root to NULL long
      ago in ->destroy(), see 47a1a1d4 ("pkt_sched: remove unnecessary xchg()
      in packet classifiers"); but the NULLifying was reintroduced with the
      RCUification, but it's not correct for every classifier implementation.
      
      In the cases that are fixed here with one exception of cls_cgroup, tp->root
      object is allocated and initialized inside ->init() callback, which is always
      performed at a point in time after we allocate a new tp, which means tp and
      thus tp->root was not globally visible in the tp chain yet (see tc_ctl_tfilter()).
      Also, on destruction tp->root is strictly kfree_rcu()'ed in ->destroy()
      handler, same for the tp which is kfree_rcu()'ed right when we return
      from ->destroy() in tcf_destroy(). This means, the head object's lifetime
      for such classifiers is always tied to the tp lifetime. The RCU callback
      invocation for the two kfree_rcu() could be out of order, but that's fine
      since both are independent.
      
      Dropping the RCU_INIT_POINTER(tp->root, NULL) for these classifiers here
      means that 1) we don't need a useless NULL check in fast-path and, 2) that
      outstanding readers of that tp in tc_classify() can still execute under
      respect with RCU grace period as it is actually expected.
      
      Things that haven't been touched here: cls_fw and cls_route. They each
      handle tp->root being NULL in ->classify() path for historic reasons, so
      their ->destroy() implementation can stay as is. If someone actually
      cares, they could get cleaned up at some point to avoid the test in fast
      path. cls_u32 doesn't set tp->root to NULL. For cls_rsvp, I just added a
      !head should anyone actually be using/testing it, so it at least aligns with
      cls_fw and cls_route. For cls_flower we additionally need to defer rhashtable
      destruction (to a sleepable context) after RCU grace period as concurrent
      readers might still access it. (Note that in this case we need to hold module
      reference to keep work callback address intact, since we only wait on module
      unload for all call_rcu()s to finish.)
      
      This fixes one race to bring RCU grace period guarantees back. Next step
      as worked on by Cong however is to fix 1e052be6 ("net_sched: destroy
      proto tp when all filters are gone") to get the order of unlinking the tp
      in tc_ctl_tfilter() for the RTM_DELTFILTER case right by moving
      RCU_INIT_POINTER() before tcf_destroy() and let the notification for
      removal be done through the prior ->delete() callback. Both are independant
      issues. Once we have that right, we can then clean tp->root up for a number
      of classifiers by not making them RCU pointers, which requires a new callback
      (->uninit) that is triggered from tp's RCU callback, where we just kfree()
      tp->root from there.
      
      Fixes: 1f947bf1 ("net: sched: rcu'ify cls_bpf")
      Fixes: 9888faef ("net: sched: cls_basic use RCU")
      Fixes: 70da9f0b ("net: sched: cls_flow use RCU")
      Fixes: 77b9900e ("tc: introduce Flower classifier")
      Fixes: bf3994d2 ("net/sched: introduce Match-all classifier")
      Fixes: 952313bd ("net: sched: cls_cgroup use RCU")
      Reported-by: NRoi Dayan <roid@mellanox.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Roi Dayan <roid@mellanox.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9363774
  19. 10 11月, 2016 2 次提交
  20. 04 11月, 2016 1 次提交
  21. 03 11月, 2016 2 次提交
  22. 28 9月, 2016 1 次提交
  23. 20 9月, 2016 1 次提交
  24. 16 9月, 2016 2 次提交
  25. 11 9月, 2016 1 次提交
    • A
      net/sched: cls_flower: Classify packet in ip tunnels · bc3103f1
      Amir Vadai 提交于
      Introduce classifying by metadata extracted by the tunnel device.
      Outer header fields - source/dest ip and tunnel id, are extracted from
      the metadata when classifying.
      
      For example, the following will add a filter on the ingress Qdisc of shared
      vxlan device named 'vxlan0'. To forward packets with outer src ip
      11.11.0.2, dst ip 11.11.0.1 and tunnel id 11. The packets will be
      forwarded to tap device 'vnet0' (after metadata is released):
      
      $ tc filter add dev vxlan0 protocol ip parent ffff: \
          flower \
            enc_src_ip 11.11.0.2 \
            enc_dst_ip 11.11.0.1 \
            enc_key_id 11 \
            dst_ip 11.11.11.1 \
          action tunnel_key release \
          action mirred egress redirect dev vnet0
      
      The action tunnel_key, will be introduced in the next patch in this
      series.
      Signed-off-by: NAmir Vadai <amir@vadai.me>
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc3103f1
  26. 29 8月, 2016 1 次提交
    • A
      net_sched: fix use of uninitialized ethertype variable in cls_flower · 0b498a52
      Arnd Bergmann 提交于
      The addition of VLAN support caused a possible use of uninitialized
      data if we encounter a zero TCA_FLOWER_KEY_ETH_TYPE key, as pointed
      out by "gcc -Wmaybe-uninitialized":
      
      net/sched/cls_flower.c: In function 'fl_change':
      net/sched/cls_flower.c:366:22: error: 'ethertype' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This changes the code to only set the ethertype field if it
      was nonzero, as before the patch.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 9399ae9a ("net_sched: flower: Add vlan support")
      Cc: Hadar Hen Zion <hadarh@mellanox.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b498a52
  27. 23 8月, 2016 1 次提交
  28. 19 8月, 2016 2 次提交
  29. 15 6月, 2016 1 次提交
  30. 08 6月, 2016 2 次提交