Sat, Oct 28, 2017 at 07:17:24PM CEST, kubak...@wp.pl wrote: >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.
Ah, will fix. Thanks!
