On 24.11, Florian Westphal wrote: > Patrick McHardy <kaber@xxxxxxxxx> wrote: > > > I'm also wondering if this introduces a race condition on architectures > > that don't support jump labels. static_key_slow_inc() simply increases > > the ->enabled counter without further synchronization, so this might > > happen while we're executing this function and some of the increments > > might be skipped. > > Hmm, adding synchronization for this is braindead. > The new trace infrastructure doesn't need this rulenum, I only kept it > since thats what Pablo asked me to do. > > So we have 3 choices: > - ignore this > - don't use static key here > - kill the old nf_log_packet trace part after all > > I find it sad that we have to keep this rule counting around :-/ > > If there are no further comments I'll remove the static key and do > the rule counting unconditinally. I wouldn't mind killing the old tracing off, but I think the main reason why we added it was for ipt compat. So probably not possible at this point. I agree that having the rule counting is not particulary nice, but I don't see any other way right now than to do it unconditionally. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
