netdev - Re: FYI: Xen or kernel bug? (fwd)

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] [day] [month] [year] [list]

Message-ID: <20070420142442.5f621ebd@dxpl.pdx.osdl.net>
Date:	Fri, 20 Apr 2007 14:24:42 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	James Morris <jmorris@...ei.org>, Mark Stier <markstier@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: FYI: Xen or kernel bug? (fwd)

On Fri, 20 Apr 2007 16:39:27 -0400 (EDT)
James Morris <jmorris@...ei.org> wrote:

> Could be an upstream kernel issue lurking.
> 
> 
> ---------- Forwarded message ----------
> Date: Fri, 20 Apr 2007 22:21:26 +0200
> From: Mark Stier <markstier@...il.com>
> To: linux-kernel@...r.kernel.org
> Subject: FYI: Xen or kernel bug?
> 
> Hello,
> 
> tcp_vegas produces division by zero kernel oopses in dom0 when running
> a Xen-patched 2.6.16.28 kernel. I have tracked down the problem to
> line #256 in tcp_vegas.c: presumably due to flaky Xen timing, the rtt
> seems to get zero from time to time (adding 1 to the rtt variable
> solves the problem for me). The same should apply to line #140 in
> tcp_veno.c, too.
> 
> Best regards,
> Mark

Something different is happening, it shouldn't be possible to get
zero there? Maybe Xen timing is so bad that you are seeing 32 bit
wraparound.

Given this, rtt can't be zero...
-----------
static void tcp_vegas_rtt_calc(struct sock *sk, u32 usrtt)
{
	struct vegas *vegas = inet_csk_ca(sk);
	u32 vrtt = usrtt + 1; /* Never allow zero rtt or baseRTT */

	/* Filter to find propagation delay: */
	if (vrtt < vegas->baseRTT)
		vegas->baseRTT = vrtt;

	/* Find the min RTT during the last RTT to find
	 * the current prop. delay + queuing delay:
	 */
	vegas->minRTT = min(vegas->minRTT, vrtt);
	vegas->cntRTT++;
--------

And we must have samples to get there.


static void tcp_vegas_cong_avoid(struct sock *sk, u32 ack,
				 u32 seq_rtt, u32 in_flight, int flag)
{
...
		 * If  we have 3 samples, we should be OK.
		 */

		if (vegas->cntRTT <= 2) {
			/* We don't have enough RTT samples to do the Vegas
			 * calculation, so we'll behave like Reno.
			 */
			tcp_reno_cong_avoid(sk, ack, seq_rtt, in_flight, flag);
		} else {
			u32 rtt, target_cwnd, diff;

			/* We have enough RTT samples, so, using the Vegas
			 * algorithm, we determine if we should increase or
			 * decrease cwnd, and by how much.
			 */
			/* Pluck out the RTT we are using for the Vegas
			 * calculations. This is the min RTT seen during the
			 * last RTT. Taking the min filters out the effects
			 * of delayed ACKs, at the cost of noticing congestion
			 * a bit later.
			 */
			rtt = vegas->minRTT;

			/* Calculate the cwnd we should have, if we weren't
			 * going too fast.
			 *
			 * This is:
			 *     (actual rate in segments) * baseRTT
			 * We keep it as a fixed point number with
			 * V_PARAM_SHIFT bits to the right of the binary point.
			 */
			target_cwnd = ((old_wnd * vegas->baseRTT)
				       << V_PARAM_SHIFT) / rtt;

So how does rtt get to zero?
There is a possible problem if RTT is ever > 4294 seconds but if you have that
big a RTT other stuff is happening.
-
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