aboutsummaryrefslogtreecommitdiffstats
path: root/net/switchdev/switchdev.c
diff options
context:
space:
mode:
authorDaniel Borkmann <[email protected]>2015-03-12 19:03:12 +0000
committerDavid S. Miller <[email protected]>2015-03-12 22:33:15 +0000
commit54720df130b3e6356391ed4f8a1a024318bcae23 (patch)
treebb15547c48f3937e6f36ffd89f0d98494c490c7e /net/switchdev/switchdev.c
parentMerge branch 'fib_trie_table_merge_fixes' (diff)
downloadkernel-54720df130b3e6356391ed4f8a1a024318bcae23.tar.gz
kernel-54720df130b3e6356391ed4f8a1a024318bcae23.zip
cls_bpf: do eBPF invocation under non-bh RCU lock variant for maps
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: e2e9b6541dd4 ("cls_bpf: add initial eBPF support for programmable classifiers") Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Diffstat (limited to 'net/switchdev/switchdev.c')
0 files changed, 0 insertions, 0 deletions