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;
> nf_conntrack_get(old->nfct);
D'oh, now that you've pointed it out it's so obvious.
> So in both cases the same reference is grabbed. Since the patch which
> put a nf_reset in ip_finish_output2 helped, I suggest following the
> code path from there and place nf_reset statements anywhere the
> packet can take a path other than to the qdiscs, that should
> help locating the problem.
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_empty(&skb->list)) {
nf_reset(skb);
}
- The net/* seems to be randomly sprinkled with nf_reset()'s without
a clear documentation as to why (ipv4/ip_input.c:ip_call_ra_chain()
for 2.6 kernel, maybe for skb_clone()'d packets), which makes it
very hard to understand.
- Where exactly do we need to nf_conntrack_put()/nf_reset() skb's?
I wonder if the remaining references should just be zeroed once we are
in the i_see_dead_people part and the call stack reveils rmmod
ip_conntrack? :)
Cheers,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
