All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Linux kernel netdev mailing list <netdev@vger.kernel.org>
Subject: Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?
Date: Mon, 27 Aug 2018 02:22:22 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.21.1808270221470.11581@localhost.localdomain> (raw)
In-Reply-To: <20180826135006.157d1bc2@xeon-e3>

On Sun, 26 Aug 2018, Stephen Hemminger wrote:

> On Sun, 26 Aug 2018 11:14:33 -0400 (EDT)
> "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
> >   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
> >
>
> There is no reason drivers should ever muck with flags directly.
> You probably are looking for netif_detach

  i assume you mean netif_device_detach; i'll check into that.

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-27 10:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 15:14 followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN? Robert P. J. Day
2018-08-26 19:24 ` 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 [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=alpine.LFD.2.21.1808270221470.11581@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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 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.