On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > > Ok, you mean for net. In that case I prefer the smaller sized fix to be > honest. It also covers everything from the point where we fetch the chain > via cops->tcf_chain() to the end of the function, which is where most of > the complexity resides, and only the two mentioned commits do the relock,
I really wish the problem is only about relocking, but look at the code, the deeper reason why we have this bug is the complexity of the logic inside tc_ctl_tfilter(): 1) the replay logic is hard, we have to make it idempotent; 2) the request logic itself is hard, because of tc filter design and implementation. This is why I worry more than just relocking. > so as a fix I think it's fine as-is. As mentioned, if there's need to > refactor tc_ctl_tfilter() net-next would be better, imho. Refactor is a too strong word, just moving the replay out is not a refactor. The end result will be still smaller than your commit d936377414fadbafb4, which is already backported to stable.
