From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965243AbcALRUA (ORCPT ); Tue, 12 Jan 2016 12:20:00 -0500 Received: from shell.v3.sk ([92.60.52.57]:37918 "EHLO shell.v3.sk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752072AbcALRT7 convert rfc822-to-8bit (ORCPT ); Tue, 12 Jan 2016 12:19:59 -0500 Message-ID: <1452619189.18559.83.camel@v3.sk> Subject: Re: [PATCH 3/3] bonding: make device count build-time configurable From: Lubomir Rintel To: Jay Vosburgh Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Veaceslav Falico , Andy Gospodarek Date: Tue, 12 Jan 2016 18:19:49 +0100 In-Reply-To: <8166.1452616452@famine> References: <1452599916-27511-1-git-send-email-lkundrak@v3.sk> <8166.1452616452@famine> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3 (3.18.3-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-01-12 at 08:34 -0800, Jay Vosburgh wrote: > Lubomir Rintel wrote: > > > The devices can be created at run-time for quite some time already > > and the > > load-time device creation collides with attempts to create the > > device of > > the same name: > > > >  # rmmod bonding > >  # ip link add bond0 type bond > >  RTNETLINK answers: File exists > > > > This is pretty much the same situation as was with the block loop > > devices > > which was solved by adding a build-time configuration that the > > distributions could use as they deem fit while keeping the default > > for > > compatibility. > > I agree this is annoying, but I would expect distros to leave > this set to 1 (for backwards compatibility with scripts that > "modprobe > bonding" then assume bond0 exists).  This leaves the problem in place > for the vast majority of users. It's still an improvement to let the distributions decide if they're keeping "ip link add" broken or possibly affecting the scripts. Given the "modprobe bonding" didn't guarantee the bond0 bevice will be around at least since 2007 it think it's very reasonable for the distros to turn this off. The network management tooling shipped with Fedora (both the legacy network service and NetworkManager) always did the right thing, be it writing to /sys/class/net/bonding_masters or adding the link via rtnetlink. Moreover, NetworkManager already specifically calls "modprobe bonding maxbonds=0" to avoid the creation of an extra "bond0" device (which coincidentally also breaks the naively written scripts if they are executed after NM creates a bond). There's also a good prior art to this; as Daniel Borkmann pointed out in [1], Fedora ships a kernel with CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 happily for 4 releases already. [1] http://marc.info/?l=linux-netdev&m=145261483331891&w=2 > Is there a reasonable way to resolve this that would actually > fix things for regular distro kernel users? Depends on the definition of reasonable. Not being very familiar with the rtnetlink code, it would perhaps be possible to create some half- finished "bond0" device before doing a request_module(), so that the subsequently loaded module wouldn't take it over. It doesn't sound like a good idea to me as it would still cause an extra "bond0" device in case the user chooses a different name and the workarounds such as the one NetworkManager uses would still be necessary. > > -J > > --- > -Jay Vosburgh, jay.vosburgh@canonical.com Lubo