Re: priv_data patch

[Patrick McHardy <kaber@trash.net>]

Joakim Axelsson wrote:
> 2006-08-14 17:31:18+0200, Patrick McHardy <kaber@trash.net> ->
> 
>>Joakim Axelsson wrote:
>>
>>>Alot of my patches can use it. Not having todo an ugly solution trying to
>>>sneak away from being reseted when another rule is altered. I sure would
>>>like to have it added. Simpyl do not change for example -m limit into using
>>>it if it breaks the "feature" of reseting its state then altering another
>>>unrelated rule.
>>
>>I forgot to reply to this. You seem to misunderstand, limit doesn't
>>reset its state today. It will when moving private data out of the
>>structures shared with userspace. Same for all other users of this,
>>they will "forget" their state on each ruleset change.
> 
> 
> Okie, now I get it. This seams to have changed from 2.4 then.

No, this behaviour has been there since the beginning.

> As altering
> one unrelated rule will trigger the checkentry for _all_ rules. The code i
> posted was a (somewhat ugly) workaround for this, and yes relying on
> userspace not altering a kernel-space pointer for us. However, the case is
> the same for xt_limit with r->master = r; (and quota). Alter master in
> userspace after the limit rule has been initiated and you will get some
> really nasty result.


Thats not true, the master pointer is reinitialized on every change by
the checkentry function (which, as you note, is called on all rules for
every change). The simple reason why it keeps its current state is
because it is dumped to userspace and echoed back. If you move it out of
the structure shared with userspace, this can not happen anymore.