All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: netdev@vger.kernel.org, bonding-devel@lists.sourceforge.net
Subject: Re: bug in bonding driver
Date: Wed, 24 Mar 2010 13:47:21 -0600	[thread overview]
Message-ID: <4BAA6C49.3040404@nortel.com> (raw)
In-Reply-To: <21160.1269458000@death.nxdomain.ibm.com>

On 03/24/2010 01:13 PM, Jay Vosburgh wrote:
> Chris Friesen <cfriesen@nortel.com> wrote:

>> The catch here is that slave->jiffies may not ever get updated after
>> being set initially, and on long-running systems jiffies will overflow.
>> That could cause this check to be true for a substantial amount of time
>> rather than for just a short period.

> 	Some quick fooling around suggests that if, for example,
> slave->jiffies is near the top of the range (ULONG_MAX - a few hundred),
> when jiffies gets up to around ULONG_MAX / 2 time_after_eq will flip
> from "after" to "before."
> 
> 	I don't think this is a particularly farfetched example, since
> jiffies is intentionally started near the top of the range, so
> slave->jiffies is likely to be high in the range after bonding is
> configured at boot.

Agreed.  If I understand it right the result of time_after_eq is only
valid if the result of the subtraction is less than LONG_MAX.

>> One way to fix it would be a boolean which tracks whether or not we've
>> gone past the time, and if we have then we don't bother actually
>> checking the time anymore.
> 
> 	It might be clearer to make the slave->jiffies some kind of
> countdown instead, perhaps reusing the slave->delay used for
> updelay/downdelay and eliminating slave->jiffies entirely.

Yes, that seems reasonable as well.

Chris

      reply	other threads:[~2010-03-24 19:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-24 18:23 bug in bonding driver Chris Friesen
2010-03-24 19:13 ` Jay Vosburgh
2010-03-24 19:47   ` Chris Friesen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BAA6C49.3040404@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=bonding-devel@lists.sourceforge.net \
    --cc=fubar@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.