Re: [Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

2005-11-29 Thread Roberto Nibali
Ok, I have tried for a couple of hours but in vain. Problems: - I don't really understand how to probe for paths not using qdiscs using skb as a source (skb->list check if list is empty?), which I would really like to do in ip_finish_output2(). Something along the lines of: if (list_empt

Re: [Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

2005-11-28 Thread Roberto Nibali
Thanks for your time, Patrick, it's very much appreciated. >> Since the rest of the assignments match I was left wondering, which >> one is correct? > > Both are fine. > 2.4: > new->nfct=old->nfct; > nf_conntrack_get(new->nfct); > 2.6: > new->nfct = old->nfct; >

Re: [Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

2005-11-28 Thread Patrick McHardy
Roberto Nibali wrote: Hello, I'm chasing down a nasty refcnt bug regarding connection tracking in 2.4.x kernels and since the nf_reset() patch for 2.6.x solving the same issue (commit: 9666dae51013b064e7d77fc36b5cee98dd167ed5) resulted in a major breakage of SO_ORIGINAL_DST support, a better

[Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

2005-11-28 Thread Roberto Nibali
Hello, I'm chasing down a nasty refcnt bug regarding connection tracking in 2.4.x kernels and since the nf_reset() patch for 2.6.x solving the same issue (commit: 9666dae51013b064e7d77fc36b5cee98dd167ed5) resulted in a major breakage of SO_ORIGINAL_DST support, a better patch was put in place