public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Linux kernel netdev mailing list <netdev@vger.kernel.org>
Subject: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?
Date: Sun, 26 Aug 2018 11:14:33 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.21.1808261102450.13415@localhost.localdomain> (raw)


  apologies for the constant pleas for assistance, but i think i'm
zeroing in on the problem that started all this. recap: custom
FPGA-based linux box with multiple ports, where the current symptom is
that there is no userspace notification when someone simply unplugs
one of the ports ("ifconfig" shows that interface still RUNNING).

  as i read it, an active ethernet interface should be both UP (the
administrative state) and RUNNING (the RFC 2863-defined operational
state). if i unplug, i've verified on a standard net port on my laptop
that the interface is still UP, but no longer RUNNING, which makes
perfect sense. i plug back in, interface starts RUNNING again. so
where's the problem?

  i can see that whether ifconfig shows an interface RUNNING is
defined in net/core/dev.c:

  unsigned int dev_get_flags(const struct net_device *dev)
  {
        unsigned int flags;

        flags = (dev->flags & ~(IFF_PROMISC |
                                IFF_ALLMULTI |
                                IFF_RUNNING |
                                IFF_LOWER_UP |
                                IFF_DORMANT)) |
                (dev->gflags & (IFF_PROMISC |
                                IFF_ALLMULTI));

        if (netif_running(dev)) {
                if (netif_oper_up(dev))
                        flags |= IFF_RUNNING;  <---- THERE
                if (netif_carrier_ok(dev))
                        flags |= IFF_LOWER_UP;
                if (netif_dormant(dev))
                        flags |= IFF_DORMANT;
        }

        return flags;
  }

where netif_oper_up() is defined as:

  static inline bool netif_oper_up(const struct net_device *dev)
  {
        return (dev->operstate == IF_OPER_UP ||
                dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
  }

so i am simply assuming that the underlying problem is that,
somewhere down below, the unplugging of a port is somehow not setting
dev->operstate to its proper value of IF_OPER_DOWN.

  that would clearly explain everything, and i'm about to dig even
further to see where the event of unplugging a port *should* be
recognized, but does this sound like a reasonable diagnosis? there
have been other problems with the programming of the FPGA, so it would
surprise absolutely no one to learn that this aspect was
misprogrammed.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

             reply	other threads:[~2018-08-26 18:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 15:14 Robert P. J. Day [this message]
2018-08-26 19:24 ` followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN? Andrew Lunn
2018-08-26 19:26   ` Robert P. J. Day
2018-08-26 20:50 ` Stephen Hemminger
2018-08-27  6:22   ` Robert P. J. Day

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=alpine.LFD.2.21.1808261102450.13415@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --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