Thanks for the feedback! Clarifications/questions inline. On Tue, Apr 22, 2025 at 1:44 AM Florian Westphal <fw@xxxxxxxxx> wrote: > > Shaun Brady <brady.1345@xxxxxxxxx> wrote: > > limit of 8192 was chosen to account for any normal use case > > Furthermore, the largest ruleset I have archived here (iptables-save > kubernetes ruleset dump) has 27k jumps (many who are mutually exclusive > and user-defined chains that are always terminal), but nf_tables_api.c > lacks the ability to detect either of these cases). > > With the proposed change, the ruleset won't load anymore. Much of my testing was omitted from the commit message. 8192 was chosen as to what seemed significantly above normal usage; I was way off. What I did observe was that machines (both big and small) start to act up around 16M. Would it ease minds to simply increase this to something like 4M or 8M? This would cover the largest case you have but keep us below the dangerous threshold. The tunable was in the event someone had an extreme use case we didn't think of, or if they wanted to be extra cautious. > > > +EXPORT_SYMBOL(sysctl_nf_max_table_jumps); > > Why is this exported? I believe I was initing at a different location that required this, and did not back this out. I will remove. > > Possible solutions to soften the impact/breakage potential: > - make the sysctl only affect non-init-net namespaces. > - make the sysctl only affect non-init-user-ns owned namespaces. I may be misunderstanding how limiting control to (only) non-init-* namespaces would help. It certainly would keep a namespace from taking the whole system down, but it would leave the original problem of being able to create the deadly jump configuration purely in the init-net. Maybe protecting from a namespace is more fruitful than an operator making mistakes (the initial revisions intent). > > - Add the obseved total jump count to the table structure > Then, when validating, do not start from 0 but from the sum > of the total jump count of all registered tables in the same family. > netdev family will need to be counted unconditionally. I had not considered one could spread the problem across multiple tables (even if you can't jump between them). This is a good insight, and I will account for this. > I think the idea is fine, but I'm not sure its going to work as-is. Glad to hear, and I would like to try for a rev2, if my question/clarifications make sense. Thanks again! SB
