netdev - Re: [iproute PATCH] iplink: Notify user if EEXIST error might be spurious

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170803155252.79050c16@xeon-e3>
Date:   Thu, 3 Aug 2017 15:52:52 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Phil Sutter <phil@....cc>
Cc:     netdev@...r.kernel.org
Subject: Re: [iproute PATCH] iplink: Notify user if EEXIST error might be
 spurious

On Tue,  1 Aug 2017 19:27:47 +0200
Phil Sutter <phil@....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@....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.