Sun, Oct 29, 2017 at 08:26:25AM CET, j...@resnulli.us wrote: >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!
We need to move tcf_block_offload_unbind(block, q, ei); call after the chains are flushed. There are big waves around this code in net and net-next atm. Will send a patch fix this once the storm is over. Thanks!
