Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751941AbYAMHft (ORCPT ); Sun, 13 Jan 2008 02:35:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751144AbYAMHfk (ORCPT ); Sun, 13 Jan 2008 02:35:40 -0500 Received: from turing-police.cc.vt.edu ([128.173.14.107]:41271 "EHLO turing-police.cc.vt.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbYAMHfi (ORCPT ); Sun, 13 Jan 2008 02:35:38 -0500 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging... From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1200209733_18681P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 13 Jan 2008 02:35:33 -0500 Message-ID: <30887.1200209733@turing-police.cc.vt.edu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5276 Lines: 112 --==_Exmh_1200209733_18681P Content-Type: text/plain; charset=us-ascii I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail is listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject mail it has just fetched from an outside server via IMAP - it will often just hang and not make any further progress. Looking at netstat shows something interesting: % netstat -n -a -A inet | grep 25 tcp 0 5108 127.0.0.1:59355 127.0.0.1:25 ESTABLISHED % netstat -n -a -A inet6 | grep 25 tcp 0 0 :::25 :::* LISTEN tcp 0 0 ::ffff:127.0.0.1:25 ::ffff:127.0.0.1:59355 ESTABLISHED % netstat -n -a -A inet | grep 25 tcp 0 5108 127.0.0.1:59355 127.0.0.1:25 ESTABLISHED % netstat -n -a -A inet6 | grep 25 tcp 0 0 :::25 :::* LISTEN tcp 0 0 ::ffff:127.0.0.1:25 ::ffff:127.0.0.1:59355 ESTABLISHED % netstat -n -a -A inet | grep 25 tcp 0 5108 127.0.0.1:59355 127.0.0.1:25 ESTABLISHED % netstat -n -a -A inet6 | grep 25 tcp 0 0 :::25 :::* LISTEN tcp 0 0 ::ffff:127.0.0.1:25 ::ffff:127.0.0.1:59355 ESTABLISHED On the IPv4 side, it thinks it's got 5108 bytes in the send queue - but on the IPv6 side of that same connection, it's showing 0 in the receive queue, and we're stuck there. It's not consistent - sometimes Fetchmail will wedge on the very first mail, and do so several times in a row. Other times, it will do well for a while - at the moment, it's gone through 471 of the 1,470 currently queued mails just fine, only to get wedged again on number 472. For what it's worth, here's what 'echo w > /proc/sysrq-trigger' got, although I don't see anything that looks odd to me given the netstat output above - procmail has sent data, and is waiting for a response back, and sendmail is waiting for data to arrive: fetchmail S ffffffff8053c520 5360 17612 9902 ffff81007d37bb08 0000000000000086 0000000000000000 000200d000000000 ffff81006bf826c0 ffffffff80687360 ffff81006bf82918 0000000000000001 0000000000000003 ffff81007d37bb88 0000000000000000 0000000000000000 Call Trace: [] schedule_timeout+0x22/0xb4 [] _spin_lock_bh+0x11/0x38 [] _spin_unlock_bh+0x1e/0x20 [] release_sock+0xa3/0xac [] sk_wait_data+0x8a/0xcf [] autoremove_wake_function+0x0/0x38 [] tcp_recvmsg+0x35a/0x86b [] sock_common_recvmsg+0x32/0x47 [] selinux_socket_recvmsg+0x1d/0x1f [] sock_recvmsg+0x10e/0x12f [] autoremove_wake_function+0x0/0x38 [] avc_has_perm+0x4c/0x5e [] pty_write+0x3a/0x44 [] remove_wait_queue+0x2f/0x3b [] sys_recvfrom+0xa4/0xf5 [] hrtimer_start+0x11f/0x131 [] do_setitimer+0x184/0x326 [] system_call_after_swapgs+0x7b/0x80 sendmail S ffff81007d30a400 5360 17613 16992 ffff81006bc419e8 0000000000000086 ffff81006bc41998 ffffffff8023f6a5 ffff81007d30a400 ffff81007d24f200 ffff81007d30a658 0000000100000286 ffff81006bc419e8 ffffffff8023f851 000000004789b768 ffff81000100eb20 Call Trace: [] lock_timer_base+0x26/0x4a [] __mod_timer+0xc4/0xd6 [] schedule_timeout+0x8d/0xb4 [] process_timeout+0x0/0xb [] schedule_timeout+0x88/0xb4 [] do_select+0x4a9/0x50b [] __pollwait+0x0/0xdf [] default_wake_function+0x0/0xf [] _spin_lock_bh+0x11/0x38 [] lock_sock_nested+0xa5/0xb2 [] _spin_lock_bh+0x11/0x38 [] _spin_unlock_bh+0x1e/0x20 [] release_sock+0xa3/0xac [] tcp_recvmsg+0x759/0x86b [] sock_common_recvmsg+0x32/0x47 [] selinux_socket_recvmsg+0x1d/0x1f [] sock_aio_read+0x121/0x139 [] avc_has_perm+0x4c/0x5e [] core_sys_select+0x1f2/0x2a0 [] page_add_new_anon_rmap+0x20/0x22 [] file_has_perm+0xa5/0xb4 [] autoremove_wake_function+0x0/0x38 [] sys_select+0x150/0x17b [] system_call_after_swapgs+0x7b/0x80 Any ideas? --==_Exmh_1200209733_18681P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFHib9FcC3lWbTT17ARApHPAJ41adCIQQPlwvolnOGw7ERE+dPRtACfVbP2 5YzB9vjZBc3kMZGAimOuUog= =B5uG -----END PGP SIGNATURE----- --==_Exmh_1200209733_18681P-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/