FYI: Xen or kernel bug? (fwd)

FYI: Xen or kernel bug? (fwd)

[James Morris]

Could be an upstream kernel issue lurking.


---------- Forwarded message ----------
Date: Fri, 20 Apr 2007 22:21:26 +0200
From: Mark Stier <markstier@gmail.com>
To: linux-kernel@vger.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
-
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/

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

[Stephen Hemminger]

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

> Could be an upstream kernel issue lurking.
> 
> 
> ---------- Forwarded message ----------
> Date: Fri, 20 Apr 2007 22:21:26 +0200
> From: Mark Stier <markstier@gmail.com>
> To: linux-kernel@vger.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.