Jozsef Kadlecsik wrote:
Oct 27 02:42:58 radek kernel: Debug: sleeping function called from
invalid context at mm/slab.c:2126
Sigh. It seems I was capable to commit all possible stupid mistakes in
iptree. Your fix is correct, expect a new release tomorrow.
Thanks a lot.
But iptree still had not members removed after specified timeout. I have
"discovered" (after reading the source code) that the iptree set need
to have set the default timeout value (with --timeout option). Is this
true or am I doing something wrong?
That is a feature. Originally iptree did not support the timeout of the
entries. In order to keep backward compatibility, the default (i.e no
timeout) is preserved.
I'm afraid I wrote it a little bit confusing :(
What I mean is that when I create iptree without default timeout:
ipset -N test iptree
and now I try to add member with timeout:
ipset -A test 1.2.3.4%60
but the timeout is not working and IP 1.2.3.4 stays in the iptree
forever. According to log messages:
kernel: net/ipv4/netfilter/ip_set_iptree.c: ip_tree_gc (DBG): gc: 1 2 3
4: expires 1 jiffies 9992264
The garbage collector is called but expires value is set to 1. I think
that it is because of the line
ipt_set_iptree.c:141 dtree->expires[d] = map->timeout ? (timeout * HZ
+ jiffies) : 1;
which sets expires to 1 when adding member with timeout to non-timeout
iptree. I think it would not break backward compatibility as old
commands do not use the ip%timeout notation.
And I've found another issue I want to ask about. Is there any
possibility to set timeout different from default timeout via ipt_SET
target?
Radek
