Re: [PATCH 0/2] rework of userspace expectation support

[Patrick McHardy <kaber@trash.net>]

Am 20.04.2011 14:10, schrieb Pablo Neira Ayuso:
> On 13/04/11 14:28, Patrick McHardy wrote:
>> I see, you're talking about unfulfilled expectations. Still, we're
>> releasing expectations in destroy_conntrack(), if we fix the refcount
>> issue, the master conntrack will not be destroyed while userspace
>> expectations exist.
> 
> I missed one point. We don't seem to increase the refcnt for unfulfilled
> expectations.

Yes, that's not necessary since unfulfilled expectations are cleaned
up once the master is destroyed. Its just the ct->master pointer of
an expected connection that takes a reference.

I thought this is what your patches try to fix?

> The following example shows a unfulfilled FTP expectation:
> 
> # conntrack -L exp
> 262 proto=6 src=192.168.1.128 dst=130.89.149.226 sport=0 dport=20412
> conntrack v1.0.0 (conntrack-tools): 1 expectations have been shown.
> 
> # conntrack -L
> tcp      6 431979 ESTABLISHED src=192.168.1.128 dst=130.89.149.226
> sport=37348 dport=21 packets=9 bytes=503 src=130.89.149.226
> dst=192.168.1.128 sport=21 dport=37348 packets=8 bytes=564 [ASSURED]
> mark=0 delta-time=29 use=1
> 
> The use field of the master conntrack shows 1.
> 
> So, I think that these patches are still the way to fix the problem with
> the expectations created through ctnetlink.

Just for my understanding, why not simply take the reference for
the master conntrack for "fulfilled" expectations (IOW conntracks
that have a master assigned), which is necessary anyways since
destroy_conntrack() attempts to release that reference again, and
clean up userspace expectations once the master conntrack vanishes?

This would match what we do for kernel expectations and I don't
really see why we would want to keep an unfulfilled userspace
expectation without the corresponding master.