All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: netdev@vger.kernel.org,
	syzbot+e73ceacfd8560cc8a3ca@syzkaller.appspotmail.com,
	syzbot+c2fb6f9ddcea95ba49b5@syzkaller.appspotmail.com,
	Jarod Wilson <jarod@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jann Horn <jannh@google.com>
Subject: Re: [Patch net] net: fix a potential recursive NETDEV_FEAT_CHANGE
Date: Tue, 05 May 2020 15:39:57 -0700	[thread overview]
Message-ID: <2833.1588718397@famine> (raw)
In-Reply-To: <20200505215819.1997-1-xiyou.wangcong@gmail.com>

Cong Wang <xiyou.wangcong@gmail.com> wrote:

>syzbot managed to trigger a recursive NETDEV_FEAT_CHANGE event
>between bonding master and slave. I managed to find a reproducer
>for this:
>
>  ip li set bond0 up
>  ifenslave bond0 eth0
>  brctl addbr br0
>  ethtool -K eth0 lro off
>  brctl addif br0 bond0
>  ip li set br0 up

	Presumably this is tied to the LRO feature being special in
netdev_sync_lower_features (via NETIF_F_UPPER_DISABLES), but why doesn't
LRO become disabled and stop the recursion once the test

		if (!(features & feature) && (lower->features & feature)) {

	no longer evalutes to true (in theory)?

	-J

>When a NETDEV_FEAT_CHANGE event is triggered on a bonding slave,
>it captures this and calls bond_compute_features() to fixup its
>master's and other slaves' features. However, when syncing with
>its lower devices by netdev_sync_lower_features() this event is
>triggered again on slaves, so it goes back and forth recursively
>until the kernel stack is exhausted.
>
>It is unnecessary to trigger it for a second time, because when
>we update the features from top down, we rely on each
>dev->netdev_ops->ndo_fix_features() to do the job, each stacked
>device should implement it. NETDEV_FEAT_CHANGE event is necessary
>when we update from bottom up, like in existing stacked device
>implementations.
>
>Just calling __netdev_update_features() is sufficient to fix this
>issue.
>
>Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
>Reported-by: syzbot+e73ceacfd8560cc8a3ca@syzkaller.appspotmail.com
>Reported-by: syzbot+c2fb6f9ddcea95ba49b5@syzkaller.appspotmail.com
>Cc: Jarod Wilson <jarod@redhat.com>
>Cc: Josh Poimboeuf <jpoimboe@redhat.com>
>Cc: Jay Vosburgh <j.vosburgh@gmail.com>
>Cc: Jann Horn <jannh@google.com>
>Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>---
> net/core/dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/net/core/dev.c b/net/core/dev.c
>index 522288177bbd..ece50ae346c3 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -8907,7 +8907,7 @@ static void netdev_sync_lower_features(struct net_device *upper,
> 			netdev_dbg(upper, "Disabling feature %pNF on lower dev %s.\n",
> 				   &feature, lower->name);
> 			lower->wanted_features &= ~feature;
>-			netdev_update_features(lower);
>+			__netdev_update_features(lower);
> 
> 			if (unlikely(lower->features & feature))
> 				netdev_WARN(upper, "failed to disable %pNF on %s!\n",
>-- 
>2.26.2
>

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

  parent reply	other threads:[~2020-05-05 22:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 21:58 [Patch net] net: fix a potential recursive NETDEV_FEAT_CHANGE Cong Wang
2020-05-05 22:27 ` Michal Kubecek
2020-05-05 22:35   ` Cong Wang
2020-05-06  5:26     ` Michal Kubecek
2020-05-06 19:08       ` Cong Wang
2020-05-06 20:15         ` Michal Kubecek
2020-05-05 22:39 ` Jay Vosburgh [this message]
2020-05-06 18:46   ` Cong Wang
2020-05-06 18:49     ` Cong Wang

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=2833.1588718397@famine \
    --to=jay.vosburgh@canonical.com \
    --cc=jannh@google.com \
    --cc=jarod@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+c2fb6f9ddcea95ba49b5@syzkaller.appspotmail.com \
    --cc=syzbot+e73ceacfd8560cc8a3ca@syzkaller.appspotmail.com \
    --cc=xiyou.wangcong@gmail.com \
    /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.