Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760821Ab0GSRjP (ORCPT ); Mon, 19 Jul 2010 13:39:15 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:60583 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760783Ab0GSRjN (ORCPT ); Mon, 19 Jul 2010 13:39:13 -0400 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=WZumzJPsohJeomXA46wktQ3pryUZxEvHpkdmu5z5fWgAFPO8XPI8VJl8lZn2vU+niG ZLecEwq5clOWqyPcsDB7ZGzVo3l3t0LwKgEp/YG0vgQYFUmhTllwgin43giBg2YDfLGQ RHrTYrbgTG2rk7b2a6ZkTBlIetbjEvu/fXCcg= Subject: Re: [PATCHv2] tcp: fix crash in tcp_xmit_retransmit_queue From: Eric Dumazet To: Ilpo =?ISO-8859-1?Q?J=E4rvinen?= Cc: Lennart Schulte , David Miller , Tejun Heo , lkml , "netdev@vger.kernel.org" , "Fehrmann, Henning" , Carsten Aulbert In-Reply-To: References: <4C358AAA.9080400@kernel.org> <4C3EF7EA.2040900@nets.rwth-aachen.de> <1279195528.2496.2.camel@edumazet-laptop> <4C3F053F.7090704@nets.rwth-aachen.de> <4C404FC5.6040107@nets.rwth-aachen.de> <4C440771.7080107@nets.rwth-aachen.de> <1279548555.2553.51.camel@edumazet-laptop> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Jul 2010 19:39:08 +0200 Message-ID: <1279561148.2553.150.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1194 Lines: 29 Le lundi 19 juillet 2010 à 20:25 +0300, Ilpo Järvinen a écrit : > This difference is well thought and intentional, I didn't use different > one by accident. We want to make sure we won't use NULL from > tcp_write_queue_head() while the pre 08ebd1721ab8fd3 kernels was > interested mainly whether the first loop should run or not (and of course > ends up avoid the null deref too but it's more optimization like > thing in there, ie., if there's no lost packets no work to-do). The deref > could have been fixed by moving TCP_SKB_CB(skb)->sacked a bit later but > that would again make us depend on the side-effect of the send_head check > (in the case of packets_out being zero and wq empty) which is something I > don't like too much. > Thanks Ilpo. Do you know in what exact circumstance the bug triggers ? It's hard to believe thousand of machines on the Internet never hit it :( Maybe another problem in congestion control ? -- 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/