Bug 495318 - Bonding driver updelay parameter actual behavior doesn't match documented behavior
Summary: Bonding driver updelay parameter actual behavior doesn't match documented beh...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.3
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jiri Pirko
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 498012
TreeView+ depends on / blocked
 
Reported: 2009-04-11 19:10 UTC by Sean E. Millichamp
Modified: 2015-05-05 01:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 498012 (view as bug list)
Environment:
Last Closed: 2009-09-02 08:59:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Removes the updelay for the first slave to become active (531 bytes, patch)
2009-04-11 19:10 UTC, Sean E. Millichamp
no flags Details | Diff
Correct version of the patch (531 bytes, patch)
2009-04-23 14:49 UTC, Sean E. Millichamp
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 08:53:34 UTC

Description Sean E. Millichamp 2009-04-11 19:10:31 UTC
Created attachment 339193 [details]
Removes the updelay for the first slave to become active

Description of problem:

The Linux kernel documentation in the kernel-doc package at Documentation/networking/bonding.txt states:

"Note that when a bonding interface has no active links, the
driver will immediately reuse the first link that goes up, even if the
updelay parameter has been specified (the updelay is ignored in this
case).  If there are slave interfaces waiting for the updelay timeout
to expire, the interface that first went into that state will be
immediately reused."

Version-Release number of selected component (if applicable):

kernel-2.6.18-128.1.6.el5

How reproducible:

Always

Steps to Reproduce:
1. Configure an active-passive bond interface with updelay set to something appropriately large (30000 or 60000)
2. From a state where the bond device and both links are up, remove both links.
3. Reconnect one,
4. Wait for the updelay to time out before the bond device returns to an operational state.
  
Expected results:

When no slaves have active links I would expect the bond device to immediately become operational after the first link-up on any slave.

Additional info:

I have tested this patch and it seems to do the right thing.  I have only tested this in an active-passive bonding configuration.

I have also sent a patch to the bonding maintainer (fubar.com) listed in MAINTAINERS rebased against 2.6.29.1 earlier today (but have not heard back from him yet).

Comment 1 Sean E. Millichamp 2009-04-23 14:49:49 UTC
Created attachment 340946 [details]
Correct version of the patch

NOTE: The original patch was accidentally a reverse diff.  This should be a correct, forward, patch.  Thanks to my coworker who was reviewing the bug and patch and asked me why I was removing the or clause... oops.

Comment 2 Jiri Pirko 2009-04-27 11:54:22 UTC
patch applied to net-next-2.6:

http://patchwork.ozlabs.org/patch/26411/

Comment 6 Don Zickus 2009-05-06 17:17:44 UTC
in kernel-2.6.18-144.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

Comment 9 errata-xmlrpc 2009-09-02 08:59:19 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html


Note You need to log in before you can comment on or make changes to this bug.