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

Reply via email to