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