Re: [Q] Adding a rule to a table, match->check_entry() behavior

2002-04-08 Thread Joakim Axelsson

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




Re: [Q] Adding a rule to a table, match->check_entry() behavior

2002-04-08 Thread Joakim Axelsson

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