Hi,
> From net/netfilter/nf_tables_core.c:
case NFT_GOTO:
chain = data[NFT_REG_VERDICT].chain;
In the GOTO case, we already point to the chain object. That chain
object is loaded in nft_immediate.c _eval(). However, the private data
of immediate is initialized in the _init() path. That means we would
need to refresh the entire rule-set to point to the correct new chain
object, otherwise we would crash.
Missed that one completely...
I'd follow a simpler solution to avoid issues. Use a fixed chain name
length (the same length as iptables does, or just 32 bytes).
We can revisit this later to see if we can support renaming and
dynamically allocated chain objects at the same time.
First solution is easy to implement, and do not imply any performance
drop, only a bit of memory loss for short names.
Second one, I cannot see anything but a 2 pass system (a hash table
handling unique handle related to a chain pointer).
But then the gain of bytes - with variable name size - versus the size
of the hash table etc... might be pointless.
Maybe I am just wrong. Is there any other solution?
Would you resend a new version of this patch?
Ok, I will go with first solution, unless you or someone else comes up
with a better proposition.
Tomasz
--
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
