From: Ido Schimmel <idosch@idosch.org>
To: Alok Tiwari <alok.a.tiwari@oracle.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, shuah@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, darren.kenny@oracle.com
Subject: Re: [PATCH] selftests: rtnetlink: Fix bridge_parent_id failure on interface state
Date: Tue, 15 Apr 2025 14:37:31 +0300 [thread overview]
Message-ID: <Z_5E-wuE6b3HyHRU@shredder> (raw)
In-Reply-To: <20250414172549.1691612-1-alok.a.tiwari@oracle.com>
On Mon, Apr 14, 2025 at 10:25:33AM -0700, Alok Tiwari wrote:
> The selftest "kci_test_bridge_parent_id" fails with the error:
> "Device can not be enslaved while up" when trying to attach interfaces
> (`eni10np1`, `eni20np1`) to a bonding device (`test-bond0`) while the
> interfaces are in the UP state.
Why are they up? The test creates the interfaces and never brings them
up.
It's most likely caused by some interface manager in your user space. I
suggest fixing that instead.
>
> Failure log:
> COMMAND: ip link set dev eni10np1 master test-bond0
> Error: Device can not be enslaved while up.
> COMMAND: ip link set dev eni20np1 master test-bond0
> Error: Device can not be enslaved while up.
> FAIL: bridge_parent_id
>
> This behavior aligns with bonding driver requirements, where a slave
> interface must be in the DOWN state before being enslaved. This was
> reinforced in upstream commit: 'ec4ffd100ffb ("Revert 'net: rtnetlink:
> Enslave device before bringing it up'")'.
>
> This patch updates the test to bring interfaces down explicitly before
> adding them to the bonding device:
I don't see why the test needs to bring them down when it never brought
them up to begin with.
prev parent reply other threads:[~2025-04-15 11:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 17:25 [PATCH] selftests: rtnetlink: Fix bridge_parent_id failure on interface state Alok Tiwari
2025-04-15 11:37 ` Ido Schimmel [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=Z_5E-wuE6b3HyHRU@shredder \
--to=idosch@idosch.org \
--cc=alok.a.tiwari@oracle.com \
--cc=darren.kenny@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@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