tipc-discussion

[Tipc-discussion] status of UDP

[Mark H. <ma...@os...>]

Jon,

What is the status of TIPC UDP?  Has it been tested very much?  I tried
loading tipc with UDP today and got lots of debug stack traces.

For instance I loaded tipc with:

insmod ./tipc.ko udp0=1 node=17 netid=1000

And started seeing these:

TIPC:  Compiled May 26 2004 07:29:42
TIPC:  Own node address <1.1.17>, network identity 1000
Debug: sleeping function called from invalid context at mm/slab.c:1967
in_atomic():1, irqs_disabled():0
Call Trace:
 [<c011cce9>] __might_sleep+0x99/0xb0
 [<c014951f>] kmem_cache_alloc+0x21f/0x230
 [<c036c70e>] sock_alloc_inode+0x1e/0x80
 [<c017f9ac>] alloc_inode+0x1c/0x140
 [<c018055d>] new_inode+0x1d/0xd0
 [<c037e742>] rtnl_lock+0x22/0x40
 [<c036ca36>] sock_alloc+0x16/0x60
 [<c036d846>] sock_create+0x86/0x230
 [<f8e5e9ec>] enable_bearer+0xac/0x470 [tipc]
 [<f8e464f7>] tipc_enable_bearer+0x227/0x4b0 [tipc]
 [<f8e5ee88>] udp_media_start+0xc8/0xd0 [tipc]
 [<f8e6b099>] tipc_init+0x99/0xa7 [tipc]
 [<c013a7b9>] sys_init_module+0x179/0x2f0
 [<c0105373>] syscall_call+0x7/0xb
                                   
TIPC:  TIPC/UDP: Multicast listener socket on 225.0.1.232:55555
TIPC:  TIPC/UDP: Unicast listener socket on port 55555
TIPC:  Bearer instance <udp:udp0> enabled, broadcast domain <1.0.0>
[root@cl017 root]# Debug: sleeping function called from invalid context at net/core/sock.c:1150
in_atomic():1, irqs_disabled():0
Call Trace:
 [<c011cce9>] __might_sleep+0x99/0xb0
 [<c0370632>] lock_sock+0x22/0xc0
 [<c0388d78>] ip_route_output_flow+0x18/0x30
 [<c03b01c4>] udp_sendmsg+0x264/0x800
 [<c0390360>] ip_finish_output2+0x0/0x1e0
 [<c03b950b>] inet_sendmsg+0x4b/0x60
 [<c036cbde>] sock_sendmsg+0x8e/0xb0
 [<c0119584>] recalc_task_prio+0xb4/0x1f0
 [<c01338cb>] kernel_text_address+0x3b/0x50
 [<c01193f8>] kernel_map_pages+0x28/0x64
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
 [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
 [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
 [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
 [<c011abc1>] scheduler_tick+0x111/0x690
 [<c0124f33>] tasklet_action+0x73/0xc0
 [<c0124c38>] __do_softirq+0xb8/0xc0
 [<c0124c75>] do_softirq+0x35/0x40
 [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
 [<c0103040>] default_idle+0x0/0x40
 [<c0105d62>] apic_timer_interrupt+0x1a/0x20
 [<c0103040>] default_idle+0x0/0x40
 [<c0103070>] default_idle+0x30/0x40
 [<c0103106>] cpu_idle+0x46/0x50
 [<c0120561>] printk+0x1c1/0x270
                                 
Debug: sleeping function called from invalid context at net/core/sock.c:1150
in_atomic():1, irqs_disabled():0
Call Trace:
 [<c011cce9>] __might_sleep+0x99/0xb0
 [<c0370632>] lock_sock+0x22/0xc0
 [<c0388d78>] ip_route_output_flow+0x18/0x30
 [<c03b01c4>] udp_sendmsg+0x264/0x800
 [<c0370c57>] __kfree_skb+0x77/0xf0
 [<c03b950b>] inet_sendmsg+0x4b/0x60
 [<c036cbde>] sock_sendmsg+0x8e/0xb0
 [<c0119584>] recalc_task_prio+0xb4/0x1f0
 [<c0119c1a>] wake_up_state+0x1a/0x20
 [<c012ac22>] signal_wake_up+0x32/0x50
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
 [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
 [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
 [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
 [<c011abc1>] scheduler_tick+0x111/0x690
 [<c0124f33>] tasklet_action+0x73/0xc0
 [<c0124c38>] __do_softirq+0xb8/0xc0
 [<c0124c75>] do_softirq+0x35/0x40
 [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
 [<c0103040>] default_idle+0x0/0x40
 [<c0105d62>] apic_timer_interrupt+0x1a/0x20
 [<c0103040>] default_idle+0x0/0x40
 [<c0103070>] default_idle+0x30/0x40
 [<c0103106>] cpu_idle+0x46/0x50
 [<c0120561>] printk+0x1c1/0x270
                                 
rmmod tipc
TIPC:  Deregistered

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] Re: status of UDP

[Jon M. <jon...@er...>]

Hi Mark,
I have not tested TIPC/UDP it on 2.6 at all; last time I did it was
with 2.4 on Vmware, not on SMP hardware. There it worked fine,
but evidently something has changed in the kernel since then.

I have a feeling that we are fighting losing battle here, trying
to use UDP in a way not anticipated in the Linux implementation.
I also got the feedback from IETF a few months ago that UDP was
very undesired as a carrier of TIPC, because it can be used over
the Internet in an uncontrollable way, without the inherent flow control
they want to se in all internet protocols. (Basically, I think they
would like to kill UDP as a protocol altogether, if they could.)

If you somhow can find an easy workaround for the problem you
see, it is ok to do it, otherwise I don't think we should spend much time
on it. We should rather remove it completely for now, and at some later
moment concentrate our effort to carry TIPC over TCP or SCTP.

What I have in mind is that we introduce a generic media
adaptation that only has the task of conveying sent/received packets
to/from a TIPC deamon in user space. It could be this daemon's task
to set up connections and transport the packets from node to node,
ensure encryption etc.
Performance would of course suffer, but for Internet protocols execution
time in the stack is not the dominating factor anyway.
For transporting packages to/from such a deamon we can use ioctl,
Netlink, or, why not, TIPC itself.

But these are future visions, I think.

Regards /Jon


Mark Haverkamp wrote:

>Jon,
>
>What is the status of TIPC UDP?  Has it been tested very much?  I tried
>loading tipc with UDP today and got lots of debug stack traces.
>
>For instance I loaded tipc with:
>
>insmod ./tipc.ko udp0=1 node=17 netid=1000
>
>And started seeing these:
>
>TIPC:  Compiled May 26 2004 07:29:42
>TIPC:  Own node address <1.1.17>, network identity 1000
>Debug: sleeping function called from invalid context at mm/slab.c:1967
>in_atomic():1, irqs_disabled():0
>Call Trace:
> [<c011cce9>] __might_sleep+0x99/0xb0
> [<c014951f>] kmem_cache_alloc+0x21f/0x230
> [<c036c70e>] sock_alloc_inode+0x1e/0x80
> [<c017f9ac>] alloc_inode+0x1c/0x140
> [<c018055d>] new_inode+0x1d/0xd0
> [<c037e742>] rtnl_lock+0x22/0x40
> [<c036ca36>] sock_alloc+0x16/0x60
> [<c036d846>] sock_create+0x86/0x230
> [<f8e5e9ec>] enable_bearer+0xac/0x470 [tipc]
> [<f8e464f7>] tipc_enable_bearer+0x227/0x4b0 [tipc]
> [<f8e5ee88>] udp_media_start+0xc8/0xd0 [tipc]
> [<f8e6b099>] tipc_init+0x99/0xa7 [tipc]
> [<c013a7b9>] sys_init_module+0x179/0x2f0
> [<c0105373>] syscall_call+0x7/0xb
>                                   
>TIPC:  TIPC/UDP: Multicast listener socket on 225.0.1.232:55555
>TIPC:  TIPC/UDP: Unicast listener socket on port 55555
>TIPC:  Bearer instance <udp:udp0> enabled, broadcast domain <1.0.0>
>[root@cl017 root]# Debug: sleeping function called from invalid context at net/core/sock.c:1150
>in_atomic():1, irqs_disabled():0
>Call Trace:
> [<c011cce9>] __might_sleep+0x99/0xb0
> [<c0370632>] lock_sock+0x22/0xc0
> [<c0388d78>] ip_route_output_flow+0x18/0x30
> [<c03b01c4>] udp_sendmsg+0x264/0x800
> [<c0390360>] ip_finish_output2+0x0/0x1e0
> [<c03b950b>] inet_sendmsg+0x4b/0x60
> [<c036cbde>] sock_sendmsg+0x8e/0xb0
> [<c0119584>] recalc_task_prio+0xb4/0x1f0
> [<c01338cb>] kernel_text_address+0x3b/0x50
> [<c01193f8>] kernel_map_pages+0x28/0x64
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
> [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
> [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
> [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
> [<c011abc1>] scheduler_tick+0x111/0x690
> [<c0124f33>] tasklet_action+0x73/0xc0
> [<c0124c38>] __do_softirq+0xb8/0xc0
> [<c0124c75>] do_softirq+0x35/0x40
> [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
> [<c0103040>] default_idle+0x0/0x40
> [<c0105d62>] apic_timer_interrupt+0x1a/0x20
> [<c0103040>] default_idle+0x0/0x40
> [<c0103070>] default_idle+0x30/0x40
> [<c0103106>] cpu_idle+0x46/0x50
> [<c0120561>] printk+0x1c1/0x270
>                                 
>Debug: sleeping function called from invalid context at net/core/sock.c:1150
>in_atomic():1, irqs_disabled():0
>Call Trace:
> [<c011cce9>] __might_sleep+0x99/0xb0
> [<c0370632>] lock_sock+0x22/0xc0
> [<c0388d78>] ip_route_output_flow+0x18/0x30
> [<c03b01c4>] udp_sendmsg+0x264/0x800
> [<c0370c57>] __kfree_skb+0x77/0xf0
> [<c03b950b>] inet_sendmsg+0x4b/0x60
> [<c036cbde>] sock_sendmsg+0x8e/0xb0
> [<c0119584>] recalc_task_prio+0xb4/0x1f0
> [<c0119c1a>] wake_up_state+0x1a/0x20
> [<c012ac22>] signal_wake_up+0x32/0x50
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
> [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
> [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
> [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
> [<c011abc1>] scheduler_tick+0x111/0x690
> [<c0124f33>] tasklet_action+0x73/0xc0
> [<c0124c38>] __do_softirq+0xb8/0xc0
> [<c0124c75>] do_softirq+0x35/0x40
> [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
> [<c0103040>] default_idle+0x0/0x40
> [<c0105d62>] apic_timer_interrupt+0x1a/0x20
> [<c0103040>] default_idle+0x0/0x40
> [<c0103070>] default_idle+0x30/0x40
> [<c0103106>] cpu_idle+0x46/0x50
> [<c0120561>] printk+0x1c1/0x270
>                                 
>rmmod tipc
>TIPC:  Deregistered
>
>  
>

[Tipc-discussion] Re: status of UDP

[Mark H. <ma...@os...>]

On Wed, 2004-05-26 at 12:36, Jon Maloy wrote:
> Hi Mark,
> I have not tested TIPC/UDP it on 2.6 at all; last time I did it was
> with 2.4 on Vmware, not on SMP hardware. There it worked fine,
> but evidently something has changed in the kernel since then.
> 
> I have a feeling that we are fighting losing battle here, trying
> to use UDP in a way not anticipated in the Linux implementation.
> I also got the feedback from IETF a few months ago that UDP was
> very undesired as a carrier of TIPC, because it can be used over
> the Internet in an uncontrollable way, without the inherent flow control
> they want to se in all internet protocols. (Basically, I think they
> would like to kill UDP as a protocol altogether, if they could.)
> 
> If you somhow can find an easy workaround for the problem you
> see, it is ok to do it, otherwise I don't think we should spend much time
> on it. We should rather remove it completely for now, and at some later
> moment concentrate our effort to carry TIPC over TCP or SCTP.
> 

I don't think that there is an easy workaround.  I looked at the udp
code last year with the original tipc and 2.5 and saw the same
problems.  I tried to use a kernel thread to process the UDP messages so
it would be in a process context but never got it to work right.

Mark.



> What I have in mind is that we introduce a generic media
> adaptation that only has the task of conveying sent/received packets
> to/from a TIPC deamon in user space. It could be this daemon's task
> to set up connections and transport the packets from node to node,
> ensure encryption etc.
> Performance would of course suffer, but for Internet protocols execution
> time in the stack is not the dominating factor anyway.
> For transporting packages to/from such a deamon we can use ioctl,
> Netlink, or, why not, TIPC itself.
> 
> But these are future visions, I think.
> 
> Regards /Jon

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] Re: status of UDP

[Jon M. <jon...@er...>]

Ok, I guess the only right thing to do is to remove it then.
I will do it next time I check in code.

/jon

Mark Haverkamp wrote:


On Wed, 2004-05-26 at 12:36, Jon Maloy wrote:

  

Hi Mark,

I have not tested TIPC/UDP it on 2.6 at all; last time I did it was

with 2.4 on Vmware, not on SMP hardware. There it worked fine,

but evidently something has changed in the kernel since then.



I have a feeling that we are fighting losing battle here, trying

to use UDP in a way not anticipated in the Linux implementation.

I also got the feedback from IETF a few months ago that UDP was

very undesired as a carrier of TIPC, because it can be used over

the Internet in an uncontrollable way, without the inherent flow control

they want to se in all internet protocols. (Basically, I think they

would like to kill UDP as a protocol altogether, if they could.)



If you somhow can find an easy workaround for the problem you

see, it is ok to do it, otherwise I don't think we should spend much
time

on it. We should rather remove it completely for now, and at some later

moment concentrate our effort to carry TIPC over TCP or SCTP.



    



I don't think that there is an easy workaround.  I looked at the udp

code last year with the original tipc and 2.5 and saw the same

problems.  I tried to use a kernel thread to process the UDP messages so

it would be in a process context but never got it to work right.



Mark.







  

What I have in mind is that we introduce a generic media

adaptation that only has the task of conveying sent/received packets

to/from a TIPC deamon in user space. It could be this daemon's task

to set up connections and transport the packets from node to node,

ensure encryption etc.

Performance would of course suffer, but for Internet protocols execution

time in the stack is not the dominating factor anyway.

For transporting packages to/from such a deamon we can use ioctl,

Netlink, or, why not, TIPC itself.



But these are future visions, I think.



Regards /Jon