On Sun, Oct 5, 2008 at 6:50 AM, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>>
>> On Saturday 2008-10-04 03:22, James King wrote:
>>
>>> I've re-written xt_layer7 (l7-filter) so that it not longer requires
>>> patching of the nf_conn structure for data storage, using ct_extend
>>> instead, with the goal that it can eventually be used against a
>>> vanilla kernel with an unpatched iptables.
>>
>> Right now, you still cannot use it with a vanilla kernel because
>> patches like #3 you attached enlarges the allocated region (remember,
>> NF_CT_EXT_NUM just increased by one!), which is going to be a big
>> impact {for users not using all the extensions} {if every imaginable
>> extensions adds itself a NF_CT_EXT_ number}.
update_alloc_size() skips over unregistered extensions, and it's a bug
to pass (id == NULL) to nf_ct_ext_add() or nf_ct_ext_create(), so
unused extensions shouldn't really impact memory allocation in terms
of allocated region size. Under patch #3, nf_cf_ext_types[] has a
single size increase by sizeof(nf_ct_ext_type), and it increases
ct->ext->offset by one u8 (so per-conntrack increase). Is this size
increase alone enough to rule it out, or am I missing something else
here?
> I think I could agree to add something like a NF_CT_EXT_LIST
> extensions that wouldn't be used by mainline, but you could
> use it for xtables-addons. There's some padding in nf_ct_ext
> so it would (currently) not have any negative impact on mainline.
> I haven't spent much though on this so it might not work though.
If adding NF_CT_EXT_LAYER7 is a no-go, I could give this a try, but I
doubt I'd have a chance to get it done before the next merge window
closes (I was hoping to have this available for 2.6.28). It would
have the same size increases noted above though, so there really
wouldn't be any difference between the two approaches (at least until
xt_layer7 is no longer the sole user).
How are the first two patches? Layering the allocation inside of a
LIST extension would probably require them anyways.
Regards,
James
--
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
