All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira <pablo@eurodev.net>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
	Netfilter Development Mailinglist
	<netfilter-devel@lists.netfilter.org>
Subject: Re: [PATCH] for some issues in tcp window tracking patch
Date: Sat, 22 May 2004 01:01:22 +0200	[thread overview]
Message-ID: <40AE8A42.9060908@eurodev.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0405211325150.7455-100000@blackhole.kfki.hu>

Hi Jozsef,

Jozsef Kadlecsik wrote:

>>a) Sometimes we destroy the conntrack calling
>>conntrack->timeout.function((unsigned long)conntrack) but we are
>>returning -NF_ACCEPT, so we are calling implicitely nf_conntrack_put
>>from conntrack core, could we have any unexpected problem?
>>    
>>
>
>Good catch, this is one of the rare cases where conntrack must explicitly
>drop the packet, so the return value should be -NF_DROP. (-NF_ACCEPT does
>not guarantee that the packet will truly be dropped, as it was discussed
>in the previous mail.)
>  
>

still one question, some tracing:

conntrack->timeout.function is death_by_timeout -> which calls 
ip_conntrack_put -> which calls nf_conntrack_put  which decrements 
refcount and if zero, we release the conntrack.

Now we return -NF_whatever, from conntrack core we call 
nf_conntrack_put, so same thing, we reduce refcount and if zero, we 
release the conntrack.

I don't know if I'm missing anything but we are decrementing twice 
conntrack refcount, at worst we could try to release an already released 
conntrack. Am I missing anything?
 

>Actually, I'm really glad that there are guys who goes trough the code,
>work hard to understand and try to improve, optimize it.
>

I do also appreciate that some people like you consider that my efforts 
are not a waste of time :-)

> We have been
>planning to submit the code for kernel inclusion for a long time, but
>it cannot be done lightheartedly, without a wider (known) test base and
>code scrutinizing by more people.
>  
>

I think that this could be an interesting new feature, as well as those 
patches to make fine grain locking in conntrack which still need some 
spins and Patrick's ipsec... well, there are interesting stuff in pom-ng.

>Compared to the cvs version, the following modifications has been added to
>my tree:
>
>- tcph->ack should be tcph->ack_seq in tcp_packet at TCP_CONNTRACK_CLOSE
>  case
>- inlined segment_seq_plus_len
>- explicit drop of SYN/ACK when the state machine is out of sync
>- releasing lock moved up, after setting timeout parameter in tcp_packet
>- IPS_ASSURED_BIT is checked before set in tcp_packet
>- SACK support added
>  
>

two issues missing:
- sender->loose decrements misplaced
- use of defined flags in tcp.h

and pending that you give your ok:
- fine grain locking for private tcp helper info

regards,
Pablo

  reply	other threads:[~2004-05-21 23:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-16 23:48 [PATCH] for some issues in tcp window tracking patch Pablo Neira
2004-05-16 23:51 ` Pablo Neira
2004-05-17 13:00 ` Jozsef Kadlecsik
2004-05-17 21:41   ` Patrick McHardy
2004-05-18  9:57     ` Pablo Neira
2004-05-18 21:10   ` Pablo Neira
2004-05-19  8:51     ` Jozsef Kadlecsik
2004-05-19 10:14       ` Pablo Neira
2004-05-20 11:27         ` Jozsef Kadlecsik
2004-05-20 23:18           ` Pablo Neira
2004-05-21  1:40             ` Henrik Nordstrom
2004-05-21  2:23               ` Patrick McHardy
2004-05-21  9:58                 ` Henrik Nordstrom
2004-05-21 16:07                   ` Patrick McHardy
2004-05-21 22:56                     ` Henrik Nordstrom
2004-05-22 13:04                       ` Stephane Ouellette
2004-05-22 14:31                       ` Patrick McHardy
2004-05-21  9:33               ` Pablo Neira
2004-05-21  8:11             ` Willy Tarreau
2004-05-21 10:06               ` Pablo Neira
2004-05-21 10:14             ` Pablo Neira
2004-05-21 12:13             ` Jozsef Kadlecsik
2004-05-21 23:01               ` Pablo Neira [this message]
2004-05-22 12:54                 ` Jozsef Kadlecsik
2004-06-01  9:48                 ` Jozsef Kadlecsik
2004-06-01 12:26                   ` Pablo Neira
2004-06-02  5:13                     ` Willy Tarreau
2004-06-08  9:55                     ` Jozsef Kadlecsik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40AE8A42.9060908@eurodev.net \
    --to=pablo@eurodev.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.