On Wed, 01 Dec 2021 12:26:14 +0100 Florian Westphal wrote: > Štěpán Němec <snemec@xxxxxxxxxx> wrote: >> Wider testing has shown that 128 kB stack is too low (e.g. for systems >> with 64 kB page size), leading to false failures in some environments. > > We could try to get rid of large on-stack allocations and always malloc > instead. [I think this might rather be a topic for discussion with other developers and maintainers, but given that I was alone in the To: header, here's my 0.02 CZK, to not leave this hanging:] My patch only addresses the regression test for one case where stack allocation lead to runaway stack. Looking for and fixing other such code paths (if any) does sound like a good idea to me. If you meant an effort to decrease nftables stack usage in general, I think I have neither the experience nor the expertise to provide an informed opinion on that. On a superficial look, nft stack size doesn't seem small, but not outrageous, either (the below is with nftables-0.9.8-9.el9.x86_64 (RHEL), but I get about the same numbers on Arch with the 1.0.1 release; both nftables and iptables rule sets were empty, but for nftables stack usage that doesn't seem to make any difference; for iptables-save it does: 51248 B with a nonempty rule set): # memusage nft list ruleset 2>&1 | grep -o 'stack peak: .*' stack peak: 98400 Same thing with iptables-save: 38352 bash -c exit: 5456 python -Sc 'exit()': 23360 python -Sm os: 70448 vim -c q: 105872 Thanks, Štěpán
