IPset_iptree with timeouts on Fedora Core 4

IPset_iptree with timeouts on Fedora Core 4

[Radek Hladik]

Greetings all,
    I have two questions regarding running ipset_iptree on Fedora Core 
4. Kernel module compilation was successful and everything was working 
on the first try except timeouts.

I tried:
ipset -N testip iptree
ipset -A testip 1.2.3.4%30
The second command produced this error in system log:

Oct 27 02:42:58 radek kernel: Debug: sleeping function called from 
invalid context at mm/slab.c:2126
Oct 27 02:42:58 radek kernel: in_atomic():1, irqs_disabled():0
Oct 27 02:42:58 radek kernel:  [<c015c27e>] kmem_cache_alloc+0x3c/0x49
Oct 27 02:42:58 radek kernel:  [<e0c8836e>] addip+0x1ae/0x1e0 
[ip_set_iptree]
Oct 27 02:42:58 radek kernel:  [<e0ca2a2c>] __ip_set_addip+0x3c/0x70 
[ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2a60>] ip_set_addip+0x0/0x10 [ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca4164>] 
ip_set_sockfn_set+0x1a4/0x4c0 [ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2a60>] ip_set_addip+0x0/0x10 [ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2a70>] ip_set_delip+0x0/0x50 [ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2ac0>] ip_set_testip+0x0/0x50 [ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2b10>] ip_set_bindip+0x0/0x170 [ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2c80>] ip_set_unbindip+0x0/0x330 
[ip_set]
Oct 27 02:42:58 radek kernel:  [<e0ca2fb0>] ip_set_testbind+0x0/0x130 
[ip_set]
Oct 27 02:42:58 radek kernel:  [<c0312f31>] nf_sockopt+0xc1/0x11f
Oct 27 02:42:58 radek kernel:  [<c0312faf>] nf_setsockopt+0x20/0x25
Oct 27 02:42:58 radek kernel:  [<c032eac1>] ip_setsockopt+0xa8/0xbc5
Oct 27 02:42:58 radek kernel:  [<e082666e>] 
__ext3_journal_stop+0x19/0x34 [ext3]
Oct 27 02:42:58 radek kernel:  [<c01ab838>] __mark_inode_dirty+0x28/0x2f0
Oct 27 02:42:58 radek kernel:  [<c01281e4>] current_fs_time+0x4e/0x69
Oct 27 02:42:58 radek kernel:  [<c0157573>] buffered_rmqueue+0xb8/0x31b
Oct 27 02:42:58 radek kernel:  [<c01576e0>] buffered_rmqueue+0x225/0x31b
Oct 27 02:42:58 radek kernel:  [<c015398d>] filemap_nopage+0x2c9/0x379
Oct 27 02:42:58 radek kernel:  [<c0165707>] do_wp_page+0x22f/0x627
Oct 27 02:42:58 radek kernel:  [<c021216c>] vsnprintf+0x32e/0x5f6
Oct 27 02:42:58 radek kernel:  [<c0199b3e>] d_alloc+0x1c/0x309
Oct 27 02:42:58 radek kernel:  [<c019b56a>] d_rehash+0xad/0x2e9
Oct 27 02:42:58 radek kernel:  [<c02fd132>] sock_map_file+0x90/0x126
Oct 27 02:42:58 radek kernel:  [<c0301499>] sock_common_setsockopt+0x20/0x26
Oct 27 02:42:58 radek kernel:  [<c02fe973>] sys_setsockopt+0x65/0xae
Oct 27 02:42:58 radek kernel:  [<c02ff0d0>] sys_socketcall+0x228/0x290
Oct 27 02:42:58 radek kernel:  [<c0103a51>] syscall_call+0x7/0xb

After googling for a while I've discovered some guy having similar 
problem with his own netfilter module and he was told to use flag 
GFP_ATOMIC instead of GFP_KERNEL in kmalloc function.
So I've changed this flag on lines 164 and 349 in file ip_set_iptree.c 
in kernel source code. This solved the problem but I'm wondering whether 
is this correct way to fix the problem?

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?

I'm running kernel 2.6.11-1.1369_FC4, iptables 1.3.0 and ipset v2.2.5 
Protocol version 2.


                                                                         
                                                   Radek Hladik

Re: IPset_iptree with timeouts on Fedora Core 4

[Jozsef Kadlecsik]

On Thu, 27 Oct 2005, Radek Hladik wrote:

> I tried:
> ipset -N testip iptree
> ipset -A testip 1.2.3.4%30
> The second command produced this error in system log:
>
> 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.

> 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.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: IPset_iptree with timeouts on Fedora Core 4

[Radek Hladik]

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

Re: IPset_iptree with timeouts on Fedora Core 4

[Jozsef Kadlecsik]

On Fri, 28 Oct 2005, Radek Hladik wrote:

> 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.

There are two possibilites:

- The set is created with a default timeout value, in which case
  all the entries time out. They can be added with specific timeout values
  by using ipset or with the default value via the SET target.
- The set is created without a timeout value (this is the default),
  when the entries do not time out. The set element which is actually
  added to the set is denoted by '1' in the line above.
  In this case there is no way to have got entries which do time out,
  not without bloating the structures, which I do not want to do.

> 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?

No, the SET target is totally generic and has no notion whatsoever on the
underlying set types.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary