From: Ido Schimmel <idosch@nvidia.com>
To: Yong Wang <yongwang@nvidia.com>
Cc: "stephen@networkplumber.org" <stephen@networkplumber.org>,
"kuba@kernel.org" <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Andy Roulin <aroulin@nvidia.com>, Nikhil Dhar <ndhar@nvidia.com>
Subject: Re: netdev: operstate UNKNOWN for loopback and other devices?
Date: Tue, 4 Feb 2025 13:58:35 +0200 [thread overview]
Message-ID: <Z6IA60rfe1oNxlYz@shredder> (raw)
In-Reply-To: <FF839E2F-B2FB-4FBB-850C-CDB62AD0D05E@nvidia.com>
On Mon, Feb 03, 2025 at 09:17:08PM +0200, Yong Wang wrote:
>
> On Wed, 20 Nov 2024 09:08:32 -0800
> Stephen Hemminger <stephen@networkplumber.org> wrote:
>
>
> >On Tue, 19 Nov 2024 19:23:53 -0800
> >Jakub Kicinski <kuba@kernel.org> wrote:
> >
> >> On Tue, 19 Nov 2024 15:37:03 -0800 Stephen Hemminger wrote:
> >> > It looks like loopback and other software devices never get the operstate
> >> > set correctly. Not a serious problem, but it is incorrect.
> >> >
> >> > For example:
> >> > $ ip -br link
> >> > lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
> >> >
> >> > tap0 UNKNOWN ca:ff:ed:bf:96:a0 <BROADCAST,PROMISC,UP,LOWER_UP>
> >> > tap1 UNKNOWN 36:f5:16:d1:4c:15 <BROADCAST,PROMISC,UP,LOWER_UP>
> >> >
> >> > For wireless and ethernet devices kernel reports UP and DOWN correctly.
> >> >
> >> > Looks like some missing bits in dev_open but not sure exactly where.
> >>
> >> I thought it means the driver doesn't have any notion of the carrier,
> >> IOW the carrier will never go down. Basically those drivers don't
> >> call netif_carrier_{on,off}() at all, and rely on carrier being on
> >> by default at netdev registration.
> >
> >Tap device does have concept of pseudo carrier. If application has file descriptor
> >open it reports carrier, if the device is present but application has not opened
> >it then carrier is reported down.
> >
>
> The UNKNOWN operstate sometimes is misleading, for loopback device, the fix seems
> simple, we can just set 'dev->operstate = IF_OPER_UP' in its initialization function
This comes from the VRF driver which is the only driver I found that
does that:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b87ab6b8e517563be372b69bdabd96c672458547
> or add ndo_open handler to call netif_carrier_no, as discussed in thread at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987#89.
I don't see a lot of value in changing this ancient behavior, but I
don't think the loopback device should be singled out either. Otherwise,
some time from now someone will complain about a different device.
next prev parent reply other threads:[~2025-02-04 11:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 19:17 netdev: operstate UNKNOWN for loopback and other devices? Yong Wang
2025-02-04 11:58 ` Ido Schimmel [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-11-19 23:37 Stephen Hemminger
2024-11-20 3:23 ` Jakub Kicinski
2024-11-20 17:08 ` Stephen Hemminger
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=Z6IA60rfe1oNxlYz@shredder \
--to=idosch@nvidia.com \
--cc=aroulin@nvidia.com \
--cc=kuba@kernel.org \
--cc=ndhar@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=yongwang@nvidia.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 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).