From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED563C282CE for ; Fri, 5 Apr 2019 21:47:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B2F0120663 for ; Fri, 5 Apr 2019 21:47:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="WhumZ6fM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726387AbfDEVry (ORCPT ); Fri, 5 Apr 2019 17:47:54 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:44974 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725973AbfDEVry (ORCPT ); Fri, 5 Apr 2019 17:47:54 -0400 Received: by mail-pf1-f196.google.com with SMTP id y13so3959544pfm.11 for ; Fri, 05 Apr 2019 14:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=pAU5yia9v3jBoHL+EyFSyeGRTxkUzKAWG/nmPwEb9HY=; b=WhumZ6fM4lDcu3mV5w6kp9IY5J23N09lVsKhZ5ud2/tilIuJdzRDHeweYZcDnqRQPp PEL+xmDnjjpTCQAcPSm7pSnY+UXZbBlDaISDj7ok8DXosKBY28lne8lUFLpW24aPkNIN ISETtKrRUuPWn8Sv/YiSdLlWRG3FoPXjC4eF8j41/N6cggyJHzNSZtkYqC57YmpMG5Jk +pUT30eOPouaseQ+Zo+ZQ/6b0DVNNn/SuQieMLBPlY9uXmAN8B6IIGUoH1/5I8b7ocQH 9VOuVnIvBXn+dgjVCht8PxxeyqxEyCR66FDznQ6xeU9Dd1TX8NCn+TfFEpGCNAgY6l2i ngwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=pAU5yia9v3jBoHL+EyFSyeGRTxkUzKAWG/nmPwEb9HY=; b=MuGlQO2kTy7356dHpB7tI+uxotsY4Qn2yQxL1zh3PxCjJ7wX9Y70S1szq7f4kYN6u7 xk5gY2iaZegLtlT5pDB9epzHyihqOi727x9txW7vZYU96mDwxQ+b8QWwlql97Zj7hHrN 1OE7W1DyGu80I/D74w5MQ+5Ez90A/UEROUgCBUNtHinbKBJAKxtxxHb/61tHzZzZylgh vb8MQdbjItkCH7KX7qam54QeFoyoKDSCW56IPE8+a1CBjDqOmG/x/ujTE3jSYJeKBP6J TGkrV0sli0QGnyk2FqxFj1Wr3TQMi1irhSgtuCKD2qLC3joKyI+jPtoT1bFugmfIBdi7 2MFw== X-Gm-Message-State: APjAAAUneSEtMo7FDIjRUdjXhFu2awASyuxDAMeXF0G6IAVhDTlBq6Nl D+feWAr8onTTaVFvmVYnBFY02g== X-Google-Smtp-Source: APXvYqxAoaEgbqpyadln3J6H6+DLXCFpCdHT6YOZvUuxaXSSvc6D2S2dMJcZIxfXSP1JYmBx8Q0oMQ== X-Received: by 2002:aa7:8c56:: with SMTP id e22mr15177013pfd.155.1554500873413; Fri, 05 Apr 2019 14:47:53 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([167.220.104.255]) by smtp.gmail.com with ESMTPSA id x24sm30900154pfn.128.2019.04.05.14.47.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 14:47:53 -0700 (PDT) Date: Fri, 5 Apr 2019 14:47:50 -0700 From: Stephen Hemminger To: "Michael S. Tsirkin" Cc: Si-Wei Liu , sridhar.samudrala@intel.com, davem@davemloft.net, kubakici@wp.pl, alexander.duyck@gmail.com, jiri@resnulli.us, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, liran.alon@oracle.com, boris.ostrovsky@oracle.com, vijay.balakrishna@oracle.com Subject: Re: [PATCH net v6] failover: allow name change on IFF_UP slave interfaces Message-ID: <20190405144750.441e396f@shemminger-XPS-13-9360> In-Reply-To: <20190405172835-mutt-send-email-mst@kernel.org> References: <1554267167-17561-1-git-send-email-si-wei.liu@oracle.com> <20190405172835-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 5 Apr 2019 17:28:55 -0400 "Michael S. Tsirkin" wrote: > On Wed, Apr 03, 2019 at 12:52:47AM -0400, Si-Wei Liu wrote: > > When a netdev appears through hot plug then gets enslaved by a failover > > master that is already up and running, the slave will be opened > > right away after getting enslaved. Today there's a race that userspace > > (udev) may fail to rename the slave if the kernel (net_failover) > > opens the slave earlier than when the userspace rename happens. > > Unlike bond or team, the primary slave of failover can't be renamed by > > userspace ahead of time, since the kernel initiated auto-enslavement is > > unable to, or rather, is never meant to be synchronized with the rename > > request from userspace. > > > > As the failover slave interfaces are not designed to be operated > > directly by userspace apps: IP configuration, filter rules with > > regard to network traffic passing and etc., should all be done on master > > interface. In general, userspace apps only care about the > > name of master interface, while slave names are less important as long > > as admin users can see reliable names that may carry > > other information describing the netdev. For e.g., they can infer that > > "ens3nsby" is a standby slave of "ens3", while for a > > name like "eth0" they can't tell which master it belongs to. > > > > Historically the name of IFF_UP interface can't be changed because > > there might be admin script or management software that is already > > relying on such behavior and assumes that the slave name can't be > > changed once UP. But failover is special: with the in-kernel > > auto-enslavement mechanism, the userspace expectation for device > > enumeration and bring-up order is already broken. Previously initramfs > > and various userspace config tools were modified to bypass failover > > slaves because of auto-enslavement and duplicate MAC address. Similarly, > > in case that users care about seeing reliable slave name, the new type > > of failover slaves needs to be taken care of specifically in userspace > > anyway. > > > > It's less risky to lift up the rename restriction on failover slave > > which is already UP. Although it's possible this change may potentially > > break userspace component (most likely configuration scripts or > > management software) that assumes slave name can't be changed while > > UP, it's relatively a limited and controllable set among all userspace > > components, which can be fixed specifically to listen for the rename > > and/or link down/up events on failover slaves. Userspace component > > interacting with slaves is expected to be changed to operate on failover > > master interface instead, as the failover slave is dynamic in nature > > which may come and go at any point. The goal is to make the role of > > failover slaves less relevant, and userspace components should only > > deal with failover master in the long run. > > > > Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module") > > Signed-off-by: Si-Wei Liu > > Reviewed-by: Liran Alon > > Acked-by: Michael S. Tsirkin > > Stephen are you happy with this approach? I think it is the best solution for what you want to do. Did you test with some things like Free Range Routing, VPP or other userspace control planes that consume netlink?