On Sat, 28 Oct 2017 10:43:51 +0200, Jiri Pirko wrote: > Sat, Oct 28, 2017 at 09:53:21AM CEST, kubak...@wp.pl wrote: > >On Sat, 28 Oct 2017 09:20:31 +0200, Jiri Pirko wrote: > >> Sat, Oct 28, 2017 at 02:52:00AM CEST, kubak...@wp.pl wrote: > >> >On Fri, 27 Oct 2017 09:27:30 +0200, Jiri Pirko wrote: > >> >> Yes, it is the same. > >> > > >> >FWIW I also see what Amritha and Alex are describing here, for cls_bpf > >> >there are no DESTROYs coming on rmmod or qdisc del. There is a DESTROY > >> >if I manually remove the filter (or if an ADD with skip_sw fails). > >> > >> Is this different to the original behaviour? Just for cls_bpf? > > > >For cls_bpf the callbacks used to be 100% symmetrical, i.e. destroy > >would always be guaranteed if add succeeded (regardless of state of > >skip_* flags). > > Hmm. It still should be symmetrical. Looking at following path: > cls_bpf_destroy-> > __cls_bpf_delete-> > cls_bpf_stop_offload-> > cls_bpf_offload_cmd(tp, prog, TC_CLSBPF_DESTROY) > > I don't see how any tp could be missed. Could you please check this > callpath is utilized during your action (rmmod or qdisc del)?
The same path seems to be utilized but the unbind comes before the filters are destroyed.
