From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH] change sk->sk_forward_alloc to atomic Date: Thu, 02 Sep 2010 23:03:33 +0200 Message-ID: <1283461413.3699.272.camel@edumazet-laptop> References: <20100902204706.29795.6982.stgit@maxim-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: netdev@vger.kernel.org To: Eric Franchoze Return-path: Received: from mail-ew0-f46.google.com ([209.85.215.46]:35934 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753478Ab0IBVDj (ORCPT ); Thu, 2 Sep 2010 17:03:39 -0400 Received: by ewy23 with SMTP id 23so667869ewy.19 for ; Thu, 02 Sep 2010 14:03:38 -0700 (PDT) In-Reply-To: <20100902204706.29795.6982.stgit@maxim-laptop> Sender: netdev-owner@vger.kernel.org List-ID: Le vendredi 03 septembre 2010 =C3=A0 00:47 +0400, Eric Franchoze a =C3=A9= crit : > Patch fixes issue bellow. > kernel: ------------[ cut here ]------------ > kernel: WARNING: at net/ipv4/af_inet.c:153 inet_sock_destruct+0xfb/0= x114() > kernel: Hardware name: PowerEdge SC1435 > kernel: Modules linked in: ipt_REJECT xt_connlimit xt_limit iptable_= filter ipt_REDIRECT xt_tcpudp xt_state xt_multiport iptable_nat nf_nat = nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables tun 80= 21q dm_mirror dm_multipath scsi_dh sbs sbshc power_meter hwmon battery = ac sg dcdbas tpm_tis tpm serio_raw tpm_bios button rtc_cmos rtc_core rt= c_lib tg3 firmware_class libphy amd64_edac_mod edac_core i2c_piix4 i2c_= core dm_region_hash dm_log dm_mod sata_svw libata sd_mod scsi_mod ext3 = jbd > kernel: Pid: 15163, comm: openvpn Tainted: G W 2.6.32.17 #3 > kernel: Call Trace: > kernel: [] ? inet_sock_destruct+0xfb/0x114 > kernel: [] warn_slowpath_common+0x77/0x8f > kernel: [] warn_slowpath_null+0xf/0x11 > kernel: [] inet_sock_destruct+0xfb/0x114 > kernel: [] __sk_free+0x1e/0xdb > kernel: [] sk_free+0x17/0x19 > kernel: [] sock_put+0x14/0x16 > kernel: [] sk_common_release+0xac/0xb1 > kernel: [] udp_lib_close+0x9/0xb > kernel: [] inet_release+0x58/0x5f > kernel: [] sock_release+0x1a/0x6c > kernel: [] sock_close+0x22/0x26 > kernel: [] __fput+0xf6/0x193 > kernel: [] fput+0x15/0x17 > kernel: [] filp_close+0x67/0x72 > kernel: [] put_files_struct+0x77/0xcb > kernel: [] exit_files+0x36/0x3b > kernel: [] do_exit+0x23f/0x65e > kernel: [] ? set_tsk_thread_flag+0xd/0xf > kernel: [] ? recalc_sigpending_tsk+0x36/0x3d > kernel: [] sys_exit_group+0x0/0x16 > kernel: [] get_signal_to_deliver+0x33a/0x38d > kernel: [] do_notify_resume+0x8c/0x6bb > kernel: [] ? _spin_lock_irqsave+0x18/0x34 > kernel: [] ? remove_wait_queue+0x4c/0x51 > kernel: [] ? do_wait+0x216/0x222 > kernel: [] ? sys_wait4+0xad/0xbf > kernel: [] int_signal+0x12/0x17 > kernel: ---[ end trace 9ae8be71cf9ee7de ]--- > Signed-off-by: Eric Franchoze You must be kidding. sk_forward_alloc will stay as it is : not atomic. Probably bug is already fixed in current kernel. Check if your kernel got commits=20 b1faf5666438090a4dc4fceac8502edc7788b7e3 (net: sock_queue_err_skb() dont mess with sk_forward_alloc) 2903037400a26e7c0cc93ab75a7d62abfacdf485 (net: fix sk_forward_alloc corruptions) 9d410c796067686b1e032d54ce475b7055537138 (net: fix sk_forward_alloc corruption)