Re: priv_data patch

[Patrick McHardy <kaber@trash.net>]

Joakim Axelsson wrote:
> 2006-08-14 17:46:59+0200, Patrick McHardy <kaber@trash.net> ->
> 
>>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.
> 
> 
> I think we define reinitiated differently then. I define reinitated by
> checkentry() being runned even tho the match/rule isn't a new (or altered)
> match/rule. 
> 
> If checkentry() is runned for _all_ matches/targers everytime an unrelated
> rule is altered then limit will lose its state because the code resets the
> bucket and refills it.


You're right. That is actually a bug in my opinion.

> Meaning that if I have a limit of 1 packet each hour
> and I change an (unrelated) rule every 30mins the limit will be a limit of 1
> packet every 30min instead. The (ugly) workaround i posted will solve this
> issue by keeping track if it has been running the checkentry() before. This
> is where the priv_data is needed.


No, we can simply check if f.e. credit is non-zero.

> But if you say that the priv_data pointer will be lost for all rules on any
> alter of rules its kinda void to have it. However a solution keeping that
> priv_data pointer intact could be very useful. 


That would mean the kernel needs to associate new rules with rules in
the old table (or the individual modules itself need to do it somehow,
like hashlimit or recent). This is really getting too ugly to even
consider in my opinion, especially since the obvious solution of not
doing an atomic table exchange also solves a lot of other problems.