Ugg, third time :-) Wasn't think clearly. You need to put this reference
counter INSIDE the allocated memory. Since iptables will run checkentry() on
one peace of memory (the new one) and destroy() on another (the old one).
Set the reference counter to 1 after allocating the memory first time
checkentry() is runned.

There :-) 

2002-04-09 05:29:57+0200, Joakim Axelsson <[EMAIL PROTECTED]> ->
> 2002-04-09 03:31:22+0200, Joakim Axelsson <[EMAIL PROTECTED]> ->
> [snip problem]
> I hate answering my own mails :-) But, I talked to Martin Josefsson and he
> told me that my observatiosn was correct. So how did I solve this problem. I
> think it can be nice for anyone else runing into this problem: 
> Typically we initiate some memory in checkentry(). However we only do this
> if userspace has set this point to NULL. This will mean that when changing
> the table the match data struct will go from kernelspace to userspace and
> back unchanged, including the pointer. When checkentry is being runned again
> it simple skips the init since it knows that it has already been initiated.
> The problem is now destroy(), how do we know when we got an actually
> destory() (our rule is remove) or just a destroy() because we changed
> another rule and thuse "reloaded" this rule. Well use a reference counter to
> help your pointer. Set the pointer to NULL and the reference counter to 0
> when first "building" the match in userspace. First time we ever run
> checkentry() in kernel we set the pointer to non NULL and the reference
> counter to 1. Every second time checkentry() is being runned (pointer is non
> NULL) on us we increase the reference count by 1. Every time destroy() is
> being runned we start by decreasing the reference count by 1. If we hit 0 we
> know that we are actually being deleted and we should deallocate the memory
> we used.
> Happy match/target writing with this tip :-)
> I still can't find the doc for how to write a match/target tho? Maybe this
> tip should be there? If not already.
> -- 
> /Gozem A.K.A. Joakim Axelsson

/Gozem A.K.A. Joakim Axelsson

Reply via email to