Re: [RFC][PATCH 0/10]: ct_extend

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 25 Jun 2007 12:16:35 +0200
> 
>>Do you think we should put these patches in 2.6.23?
> 
> 
> I think it's ready.

Great.

> I've re-checked race at nf_conntrack_netlink and I think there is no
> race on members in nfct_nat(ct) at ct_netlink_change_helper(). Because
> 
> - 'bysource' and 'ct' are protected by nf_nat_lock when the area of
>   nfct_nat(ct) is reallocated.
> - 'seq' and 'help' are used by only helper, but we don't change helper.
>   So there is no race.
> - 'masq_index' is set in ipt_MASQUERADE.c while conntrack is
>   unconfirmed. Besides nfctnetlink can change only confirmed conntracks.
>   And 'masq_index' in confirmed conntrack is never changed.

Sounds right.

> BTW, I don't understand why ipt_MQASQUERADE needs lock. I think there is no
> difference of results if we remove the lock. If we want to completely
> discards conntracks related to output device, MASQUERADE should wait
> in *_event() until all packets pass through network stack. But I'm not sure
> it's possible.


Yes it looks unnecessary. Reliably removing all conntracks is not
really necessary, its only an optimization to keep the table smaller.

I'm actually happy about every missed connection since my DSL line
has an almost permanent address and connections usually live on
after a reconnect unless NAT remaps them :)