diff options
| author | Daniel Borkmann <daniel@iogearbox.net> | 2015-03-12 22:03:12 +0300 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2015-03-13 01:33:15 +0300 |
| commit | 54720df130b3e6356391ed4f8a1a024318bcae23 (patch) | |
| tree | bb15547c48f3937e6f36ffd89f0d98494c490c7e /include/net/inet_sock.h | |
| parent | 06741d055bb1a630f793e36a486a209698ea672b (diff) | |
| download | linux-54720df130b3e6356391ed4f8a1a024318bcae23.tar.xz | |
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 <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/net/inet_sock.h')
0 files changed, 0 insertions, 0 deletions