From: Daniel Borkmann
Date: Mon, 27 Nov 2017 22:09:33 +0100
> On 11/27/2017 08:11 PM, Jakub Kicinski wrote:
>> When cls_bpf offload was added it seemed like a good idea to
>> call cls_bpf_delete_prog() instead of extending the error
>> handling path, since the software state is fully initialized
On Mon, Nov 27, 2017 at 11:11 AM, Jakub Kicinski
wrote:
> When cls_bpf offload was added it seemed like a good idea to
> call cls_bpf_delete_prog() instead of extending the error
> handling path, since the software state is fully initialized
> at that point. This handling of errors without jumpin
On 11/27/2017 08:11 PM, Jakub Kicinski wrote:
> When cls_bpf offload was added it seemed like a good idea to
> call cls_bpf_delete_prog() instead of extending the error
> handling path, since the software state is fully initialized
> at that point. This handling of errors without jumping to
> the
When cls_bpf offload was added it seemed like a good idea to
call cls_bpf_delete_prog() instead of extending the error
handling path, since the software state is fully initialized
at that point. This handling of errors without jumping to
the end of the function is error prone, as proven by later
c
