[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-net
Subject:    tcp_connect context issue
From:       Juha Heljoranta <juha.heljoranta () evtek ! fi>
Date:       2005-04-26 15:10:33
Message-ID: 426E59E9.8060804 () evtek ! fi
[Download RAW message or body]

Hi,

It seems that the kernel enters into interrupt context at some point
when user space process issues connect.

I made a stack dump but I cannot figure out from it at what point
context switch takes place. What function should I look at?

Dump is from vanilla 2.6.10 (user mode linux guest kernel).

Apr 26 17:54:49 virtual [<a01c0167>] match+0x57/0x2f0
Apr 26 17:54:49 virtual [<a00475bb>] local_bh_enable+0xb/0x80
Apr 26 17:54:49 virtual [<a01b9fa7>] tcp_packet+0x1c7/0x6e0
Apr 26 17:54:49 virtual [<a00475bb>] local_bh_enable+0xb/0x80
Apr 26 17:54:49 virtual [<a01bb3fa>] ipt_do_table+0x2ea/0x500
Apr 26 17:54:49 virtual [<a01bb356>] ipt_do_table+0x246/0x500
Apr 26 17:54:49 virtual [<a01be3c0>] ipt_local_out_hook+0x70/0x80
Apr 26 17:54:49 virtual [<a0173ca5>] nf_iterate+0x65/0xc0
Apr 26 17:54:49 virtual [<a0184b50>] dst_output+0x0/0x30
Apr 26 17:54:49 virtual [<a0173fb0>] nf_hook_slow+0x90/0x150
Apr 26 17:54:49 virtual [<a0184b50>] dst_output+0x0/0x30
Apr 26 17:54:49 virtual [<a0182b67>] ip_queue_xmit+0x3f7/0x530
Apr 26 17:54:49 virtual [<a0184b50>] dst_output+0x0/0x30
Apr 26 17:54:49 virtual [<a001cb54>] get_signals+0x34/0x50
Apr 26 17:54:49 virtual [<a001ca42>] change_signals+0x62/0x90
Apr 26 17:54:49 virtual [<a007737d>] check_poison_obj+0x2d/0x1e0
Apr 26 17:54:49 virtual [<a0076cb7>] dbg_redzone1+0x17/0x50
Apr 26 17:54:49 virtual [<a00794ef>] cache_alloc_debugcheck_after+0x3f/0x170
Apr 26 17:54:49 virtual [<a019bc50>] tcp_v4_send_check+0x50/0xf0
Apr 26 17:54:49 virtual [<a0194e90>] tcp_transmit_skb+0x440/0x790
Apr 26 17:54:49 virtual [<a01977e9>] tcp_connect+0x2c9/0x370
Apr 26 17:54:49 virtual [<a019afe1>] tcp_v4_connect+0x3e1/0x6f0
Apr 26 17:54:49 virtual [<a00475bb>] local_bh_enable+0xb/0x80
Apr 26 17:54:49 virtual [<a01acbf4>] inet_stream_connect+0x84/0x1d0
Apr 26 17:54:49 virtual [<a0159d31>] move_addr_to_kernel+0x61/0x70
Apr 26 17:54:49 virtual [<a015bb7e>] sys_connect+0x8e/0xb0
Apr 26 17:54:49 virtual [<a0027182>] buffer_op+0x42/0x70
Apr 26 17:54:49 virtual [<a0026ff0>] do_buffer_op+0x0/0x150
Apr 26 17:54:49 virtual [<a00271b0>] copy_chunk_from_user+0x0/0x40
Apr 26 17:54:49 virtual [<a0027252>] copy_from_user_skas+0x62/0x80
Apr 26 17:54:49 virtual [<a00271b0>] copy_chunk_from_user+0x0/0x40
Apr 26 17:54:49 virtual [<a015c7bf>] sys_socketcall+0xbf/0x270
Apr 26 17:54:49 virtual [<a001ed58>] handle_page_fault+0x168/0x200
Apr 26 17:54:49 virtual [<a001ef19>] segv+0x89/0x1f0
Apr 26 17:54:49 virtual [<a0026881>] execute_syscall_skas+0xd1/0x120
Apr 26 17:54:49 virtual [<a001da99>] record_syscall_start+0x59/0x70
Apr 26 17:54:49 virtual [<a002690e>] handle_syscall+0x3e/0x80
Apr 26 17:54:49 virtual [<a002584c>] handle_trap+0x3c/0x160
Apr 26 17:54:49 virtual [<a0025e7f>] save_registers+0x3f/0x70
Apr 26 17:54:49 virtual [<a0025cb2>] userspace+0x182/0x1b0
Apr 26 17:54:49 virtual [<a01db238>] __restore+0x0/0x8
Apr 26 17:54:49 virtual [<a01db2e1>] kill+0x11/0x20

What I am doing is an improved version from ipt_owner.c.

I can locate process that issues connect when second syn packet is sent
(first packet is dropped) because process goes into sk->sk_sleep or into
sk->sk_socket->fasync_list at some point between the packets.

Regards,
Juhe Heljoranta
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]