On 05.03, Pablo Neira Ayuso wrote: > On Thu, Mar 05, 2015 at 05:13:53PM +0000, Patrick McHardy wrote: > > I think this case shouldn't exist at all since it codifies kernel > > internals into the API. Today we might accept 128 expressions, the > > other day just 100, all depending on 32 or 64 bit systems. Its not > > good. > > > > The problem is I also don't want to increase the maximum rule size > > to more than 4k since this will run into issues with memory > > fragmentation. I think we need to decrease NFT_EXPR_MAXNUM, its > > unreasonable large, and then add a per expression maximum size. > > Yes, that's more than anyone would need I guess. We used to have a > couple of crazy tests in iptables with lots of matches in one rule > (maps to one expression each) that were hitting the limit. So my > motivation was to avoid hitting that it from nft_compat. Assuming that > the info area consumes ~32 bytes and 128 expressions, we would exactly > reach the limit. But there are xtables extensions consuming more than > that for the info area, so we may hit the limit before those 128 > expressions with this check. I think that's OK, we should consider > realistic scenarios, not too crazy tests. Agreed, it doesn't really matter. But I still believe the API should not potentially fail because of kernel internal changes. I'd rather have strict limits that kick in *before* we use up all our space and those crazy test cases simply won't work with nftables. > > For now I'd say apply it as it is, keep the different errno code > > since its a really different case, and we'll fix up the underlying > > problem after a bit more of thought. > > Sure, thanks for the explanation. -- 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
