[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cb06e7c6-2042-1243-fe6e-3e1e33e4b14d@solarflare.com>
Date: Thu, 16 Aug 2018 19:34:12 +0100
From: Edward Cree <ecree@...arflare.com>
To: Petar Penkov <peterpenkov96@...il.com>, <netdev@...r.kernel.org>
CC: <davem@...emloft.net>, <ast@...nel.org>, <daniel@...earbox.net>,
<simon.horman@...ronome.com>, Petar Penkov <ppenkov@...gle.com>,
"Willem de Bruijn" <willemb@...gle.com>
Subject: Re: [bpf-next RFC 1/3] flow_dissector: implements flow dissector BPF
hook
On 16/08/18 17:44, Petar Penkov wrote:
> From: Petar Penkov <ppenkov@...gle.com>
>
> Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
> attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
> path. The BPF program is kept as a global variable so it is
> accessible to all flow dissectors.
>
> Signed-off-by: Petar Penkov <ppenkov@...gle.com>
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
> ---
This looks really great.
> +int skb_flow_dissector_bpf_prog_detach(const union bpf_attr *attr)
> +{
> + struct bpf_prog *attached;
> +
> + mutex_lock(&flow_dissector_mutex);
> + attached = rcu_dereference_protected(flow_dissector_prog,
> + lockdep_is_held(&flow_dissector_mutex));
> + if (!flow_dissector_prog) {
> + mutex_unlock(&flow_dissector_mutex);
> + return -EINVAL;
Wouldn't -ENOENT be more usual here (as the counterpart to -EEXIST in
the skb_flow_dissector_bpf_prog_attach() version just above)?
-Ed
Powered by blists - more mailing lists