netdev - Re: TCP sacked_out and fackets_out inconsistency (Was: Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F3231C1.9040509@profihost.ag>
Date:	Wed, 08 Feb 2012 09:26:41 +0100
From:	Stefan Priebe - Profihost AG <s.priebe@...fihost.ag>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Miller <davem@...emloft.net>, jwboyer@...il.com,
	hch@...radead.org, Netdev <netdev@...r.kernel.org>,
	david@...morbit.com, stable@...r.kernel.org,
	Greg KH <gregkh@...e.de>
Subject: Re: TCP sacked_out and fackets_out inconsistency (Was: Re: BUG: unable
 to handle kernel NULL pointer dereference at 000000000000002c)

Hi Eric,

Am 06.02.2012 13:47, schrieb Ilpo Järvinen:
>>> Any idea about that? Is it due to my custom patch being buggy or is it
>>> anything you know which is missing in 3.0.X too?
> 
> This warning is known to trigger every now and then...
> 
>> Thats the tcp_fastretrans_alert()
>>
>> 	if (WARN_ON(!tp->sacked_out && tp->fackets_out))
>> 		tp->fackets_out = 0;
>>
>> I dont know if some recent patch addressed this issue.
> 
> ...the recent fix from Neal to pick correct MSS might fix this but it 
> is of course hard to confirm for sure (we'll see it indirectly eventually 
> if there won't be anymore these rare splats). If one has infinite time it 
> would be quite simple to see if changing mss setup triggers this and if 
> the Neal's fix helped or not, however, I don't consider this particular 
> inconsistency worth the effort.
> 
> ...What I can say for sure is at least tp->fackets_out -= min(pkts_acked, 
> tp->fackets_out); seems to fail when pkts_acked (u32) underflows due to 
> the mss badness we used to have. So it could actually solve this for real.
> 
> The effects of this counter inconsistency are not that devastating. 
> Fackets_out mainly affect when recovery is triggered/which segments to 
> mark lost in the recovery itself. Two extremes I can think of: recovery 
> not triggered => RTO triggers and everyone is happy except some researcher 
> who finds that odd and unwanted and needs to fix it :-); recovery in 
> progress but works too much ahead, as if dupthresh (tp->reordering) would 
> be slightly smaller (if in-order behavior in the network is assumed this 
> is still fully safe, dupthresh is there to help in cases of minor 
> reordering).

What do you think about this? Can anybody give me the commit id?

Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html