Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932772Ab0KLSWA (ORCPT ); Fri, 12 Nov 2010 13:22:00 -0500 Received: from mail-ww0-f44.google.com ([74.125.82.44]:52658 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932296Ab0KLSV6 (ORCPT ); Fri, 12 Nov 2010 13:21:58 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=H/bknx+7hmqsWHycTxiUVqIKVWjErn38eJpHBwzWsoobAClXRlHF4PjvUXbr6TvkFl +v0BPEfs0Z/GXl+y3IWlcJScw+HG+DvYIgnfYFXL6X5495NcJd1b4H4uxKj5h3W3paEB j1FHcUZx1DdaPZLIl+FkGa1tRnkxke/gLk9+c= Subject: Re: a problem tcp_v4_err() From: Eric Dumazet To: Alexey Kuznetsov Cc: Patrick McHardy , David Lamparter , Eric Paris , Hua Zhong , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davem@davemloft.net, pekkas@netcore.fi, jmorris@namei.org, yoshfuji@linux-ipv6.org, paul.moore@hp.com In-Reply-To: <1289585578.3185.268.camel@edumazet-laptop> References: <20101111210341.31350.86916.stgit@paris.rdu.redhat.com> <00c201cb81eb$84e18160$8ea48420$@com> <1289578108.3083.95.camel@localhost.localdomain> <1289578532.3185.265.camel@edumazet-laptop> <20101112163543.GB122902@jupiter.n2.diac24.net> <4CDD7145.8070606@trash.net> <20101112175715.GB16544@ms2.inr.ac.ru> <1289585578.3185.268.camel@edumazet-laptop> Content-Type: text/plain; charset="UTF-8" Date: Fri, 12 Nov 2010 19:21:54 +0100 Message-ID: <1289586114.3185.271.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1358 Lines: 49 Le vendredi 12 novembre 2010 à 19:12 +0100, Eric Dumazet a écrit : > Le vendredi 12 novembre 2010 à 20:57 +0300, Alexey Kuznetsov a écrit : > > Hello! > > > > I looked at tcp_v4_err() and found something strange. Quite non-trivial operations > > are performed on unlocked sockets. It looks like at least this BUG_ON(): > > > > skb = tcp_write_queue_head(sk); > > BUG_ON(!skb); > > > > can be easily triggered. > > > > Do I miss something? > > > > Hi Alexey ! > > I see socket is locked around line 368, > > bh_lock_sock(sk); > /* If too many ICMPs get dropped on busy > * servers this needs to be solved differently. > */ > if (sock_owned_by_user(sk)) > NET_INC_STATS_BH(net, LINUX_MIB_LOCKDROPPEDICMPS); > > > Hmm, maybe some goto is missing ;) > Well, goto is not missing. Why do you think BUG_ON(!skb) can be triggered ? We test before : if (seq != tp->snd_una || !icsk->icsk_retransmits || !icsk->icsk_backoff) break; So a concurrent user only can add new skb(s) in the (non empty) queue ? -- 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/