From: Toby Corkindale <tjc@wintrmute.net>
To: netdev@vger.kernel.org
Subject: Re: Regression in bonding driver - devices without set_mac
Date: Fri, 6 Nov 2015 10:12:13 +1100 [thread overview]
Message-ID: <CABEgq976udiL1nAjNte0dOTreeX2PvJOJggaKT_fs_9WYH4w-w@mail.gmail.com> (raw)
In-Reply-To: <CABEgq97hxgNJWne48amV9M74VbMaTG7fuxfyRti0qCBFGAW1jg@mail.gmail.com>
OK, wow, this list is super high traffic. I'm going to unsubscribe now.
Feel free to get in contact with me directly (not via the list) if you like.
It'd be lovely if someone wants to fix the regression I reported,
especially as it looks pretty simple to achieve. (Just don't silently fail
if you can't get a MAC address for the netlink info).
Bye,
Toby
On 4 November 2015 at 18:45, Toby Corkindale <tjc@wintrmute.net> wrote:
>
> On 4 November 2015 at 14:49, Toby Corkindale <tjc@wintrmute.net> wrote:
> > Hi,
> > I've subscribed to this list to try and sort out a regression in the
> > bonding network driver.
> > I originally reported this in Dec 2014, as:
> > https://bugzilla.kernel.org/show_bug.cgi?id=89161
> >
> > The bug is still present in the 4.2 Linux kernel.
> >
> > If you look at the code, here:
> > https://github.com/torvalds/linux/commit/f54424412b6b2f64cae4d7c39d981ca14ce0052c
> >
> > Then you see that the intention is for devices without set_mac support
> > to be supported. Although in older code they DID work, and that
> > ability died sometime near this commit. And has never returned since.
> >
> > The code path in current kernels does allow devices through that block
> > of code, but it fails somewhere else -- the devices are not
> > successfully added as slaves, but the only error printed is the
> > warning about not supporting MAC address setting.
> >
> > Is there anything I can do to try and sort this regression out, with you?
> >
> > I can explain how to set up two virtual machines with PPPoE client and
> > server in order to test, if you like? Or I can try out patches and
> > give feedback.
> >
> > Cheers
> > Toby
>
>
> The following patch fixes the regression, for me, although I suspect
> it's not suitable for direct application.
> But maybe knowing that it fixes the issue, helps you create something
> appropriate?
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 771a449..3f44875 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1460,8 +1460,8 @@ int bond_enslave(struct net_device *bond_dev,
> struct net_device *slave_dev
> )
> addr.sa_family = slave_dev->type;
> res = dev_set_mac_address(slave_dev, &addr);
> if (res) {
> - netdev_dbg(bond_dev, "Error %d calling set_mac_address\n", res);
> - goto err_restore_mtu;
> + netdev_warn(bond_dev, "Error %d calling set_mac_address\n", res);
> }
> }
>
> diff --git a/drivers/net/bonding/bond_netlink.c
> b/drivers/net/bonding/bond_netlink.c
> index db760e8..e4ffc94 100644
> --- a/drivers/net/bonding/bond_netlink.c
> +++ b/drivers/net/bonding/bond_netlink.c
> @@ -49,9 +49,8 @@ static int bond_fill_slave_info(struct sk_buff *skb,
> slave->link_failure_count))
> goto nla_put_failure;
>
> - if (nla_put(skb, IFLA_BOND_SLAVE_PERM_HWADDR,
> - slave_dev->addr_len, slave->perm_hwaddr))
> - goto nla_put_failure;
> + nla_put(skb, IFLA_BOND_SLAVE_PERM_HWADDR, slave_dev->addr_len,
> slave->perm_hwaddr);
>
> if (nla_put_u16(skb, IFLA_BOND_SLAVE_QUEUE_ID, slave->queue_id))
> goto nla_put_failure;
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
next prev parent reply other threads:[~2015-11-05 23:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 3:49 Regression in bonding driver - devices without set_mac Toby Corkindale
2015-11-04 7:45 ` Toby Corkindale
2015-11-05 23:12 ` Toby Corkindale [this message]
2015-11-06 22:46 ` Jay Vosburgh
[not found] ` <CABEgq96o2dXi06rLh6xmLGYVzh0-fVPs0rpjv8X3NTsk_=8+JQ@mail.gmail.com>
2015-11-07 2:31 ` Jay Vosburgh
2015-11-07 6:05 ` Toby Corkindale
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=CABEgq976udiL1nAjNte0dOTreeX2PvJOJggaKT_fs_9WYH4w-w@mail.gmail.com \
--to=tjc@wintrmute.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).