[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180117.171439.788165644589558195.davem@davemloft.net>
Date: Wed, 17 Jan 2018 17:14:39 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: daniel@...earbox.net
Cc: jakub.kicinski@...ronome.com, ast@...com, netdev@...r.kernel.org
Subject: Re: [PATCH net] bpf: fix cls_bpf on filter replace
From: Daniel Borkmann <daniel@...earbox.net>
Date: Wed, 17 Jan 2018 22:36:49 +0100
> Running the following sequence is currently broken:
>
> # tc qdisc add dev foo clsact
> # tc filter replace dev foo ingress prio 1 handle 1 bpf da obj bar.o
> # tc filter replace dev foo ingress prio 1 handle 1 bpf da obj bar.o
> RTNETLINK answers: Invalid argument
>
> The normal expectation on kernel side is that the second command
> succeeds replacing the existing program. However, what happens is
> in cls_bpf_change(), we bail out with err in the second run in
> cls_bpf_offload(). The EINVAL comes directly in cls_bpf_offload()
> when comparing prog vs oldprog's gen_flags. In case of above
> replace the new prog's gen_flags are 0, but the old ones are 8,
> which means TCA_CLS_FLAGS_NOT_IN_HW is set (e.g. drivers not having
> cls_bpf offload).
>
> Fix 102740bd9436 ("cls_bpf: fix offload assumptions after callback
> conversion") in the following way: gen_flags from user space passed
> down via netlink cannot include status flags like TCA_CLS_FLAGS_IN_HW
> or TCA_CLS_FLAGS_NOT_IN_HW as opposed to oldprog that we previously
> loaded. Therefore, it doesn't make any sense to include them in the
> gen_flags comparison with the new prog before we even attempt to
> offload. Thus, lets fix this before 4.15 goes out.
>
> Fixes: 102740bd9436 ("cls_bpf: fix offload assumptions after callback conversion")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Acked-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
Applied, thanks Daniel.
Powered by blists - more mailing lists