public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber•org>
To: Phil Sutter <phil@nwl•cc>
Cc: netdev@vger•kernel.org
Subject: Re: [iproute PATCH] iplink: Notify user if EEXIST error might be spurious
Date: Thu, 3 Aug 2017 15:52:52 -0700	[thread overview]
Message-ID: <20170803155252.79050c16@xeon-e3> (raw)
In-Reply-To: <20170801172747.2817-1-phil@nwl.cc>

On Tue,  1 Aug 2017 19:27:47 +0200
Phil Sutter <phil@nwl•cc> wrote:

> Back in the days when RTM_NEWLINK wasn't yet implemented, people had to
> rely upon kernel modules to create (virtual) interfaces for them. The
> number of those was usually defined via module parameter, and a sane
> default value was chosen. Now that iproute2 allows users to instantiate
> new interfaces at will, this is no longer required - though for
> backwards compatibility reasons, we're stuck with both methods which
> collide at the point when one tries to create an interface with a
> standard name for a type which exists in a kernel module: The kernel
> will load the module, which instantiates the interface and the following
> RTM_NEWLINK request will fail since the interface exists already. For
> instance:
> 
> | # lsmod | grep dummy
> | # ip link show | grep dummy0
> | # ip link add dummy0 type dummy
> | RTNETLINK answers: File exists
> | # ip link show | grep -c dummy0
> | 1
> 
> There is no race-free solution in userspace for this dilemma as far as I
> can tell, so try to detect whether a user might have run into this and
> notify that the given error message might be irrelevant.
> 
> Signed-off-by: Phil Sutter <phil@nwl•cc>

There is already a workable solution. There is already module parameters to block autocreation
in bonding and dummy network device. The others should have it as well.

This patch just seems like creating more clutter.

      reply	other threads:[~2017-08-03 22:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-01 17:27 [iproute PATCH] iplink: Notify user if EEXIST error might be spurious Phil Sutter
2017-08-03 22:52 ` Stephen Hemminger [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=20170803155252.79050c16@xeon-e3 \
    --to=stephen@networkplumber$(echo .)org \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=phil@nwl$(echo .)cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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