1. 13 Mar, 2015 36 commits
  2. 12 Mar, 2015 4 commits
    • Daniel Borkmann's avatar
      cls_bpf: do eBPF invocation under non-bh RCU lock variant for maps · 54720df1
      Daniel Borkmann authored
      Currently, it is possible in cls_bpf to access eBPF maps only under
      rcu_read_lock_bh() variants: while on ingress side, that is, handle_ing(),
      the classifier would be called from __netif_receive_skb_core() under
      rcu_read_lock(); on egress side, however, it's rcu_read_lock_bh() via
      __dev_queue_xmit().
      
      This rcu/rcu_bh mix doesn't work together with eBPF maps as they require
      soley to be called under rcu_read_lock(). eBPF maps could also be shared
      among various other eBPF programs (possibly even with other eBPF program
      types, f.e. tracing) and user space processes, so any context is assumed.
      
      Therefore, a possible fix for cls_bpf is to wrap/nest eBPF program
      invocation under non-bh RCU lock variant.
      
      Fixes: e2e9b654 ("cls_bpf: add initial eBPF support for programmable classifiers")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54720df1
    • David S. Miller's avatar
      Merge branch 'fib_trie_table_merge_fixes' · 06741d05
      David S. Miller authored
      Alexander Duyck says:
      
      ====================
      fib_trie: Minor fixes for table merge
      
      This patch set addresses two issues reported with the tables merged, the
      first is a NULL pointer dereference, and the other is to remove a WARN_ON
      and set the ordering for aliases from different tables with the same slen
      values.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06741d05
    • Alexander Duyck's avatar
      fib_trie: Provide a deterministic order for fib_alias w/ tables merged · 0b65bd97
      Alexander Duyck authored
      This change makes it so that we should always have a deterministic ordering
      for the main and local aliases within the merged table when two leaves
      overlap.
      
      So for example if we have a leaf with a key of 192.168.254.0.  If we
      previously added two aliases with a prefix length of 24 from both local and
      main the first entry would be first and the second would be second.  When I
      was coding this I had added a WARN_ON should such a situation occur as I
      wasn't sure how likely it would be.  However this WARN_ON has been
      triggered so this is something that should be addressed.
      
      With this patch the ordering of the aliases is as follows.  First they are
      sorted on prefix length, then on their table ID, then tos, and finally
      priority.  This way what we end up doing is essentially interleaving the
      two tables on what used to be leaf_info structure boundaries.
      
      Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse")
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b65bd97
    • Alexander Duyck's avatar
      fib_trie: Avoid NULL pointer if local table is not allocated · 3c9e9f73
      Alexander Duyck authored
      The function fib_unmerge assumed the local table had already been
      allocated.  If that is not the case however when custom rules are applied
      then this can result in a NULL pointer dereference.
      
      In order to prevent this we must check the value of the local table pointer
      and if it is NULL simply return 0 as there is no local table to separate
      from the main.
      
      Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse")
      Reported-by: default avatarMadhu Challa <challa@noironetworks.com>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c9e9f73