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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 2607AC43381 for ; Thu, 28 Feb 2019 14:26:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F37E12171F for ; Thu, 28 Feb 2019 14:26:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732933AbfB1O0N (ORCPT ); Thu, 28 Feb 2019 09:26:13 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:34204 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727831AbfB1O0K (ORCPT ); Thu, 28 Feb 2019 09:26:10 -0500 Received: by mail-qt1-f196.google.com with SMTP id w4so23702084qtc.1 for ; Thu, 28 Feb 2019 06:26:09 -0800 (PST) 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:references :mime-version:content-disposition:in-reply-to; bh=lb9ZWPm0sqUiur31uDrSAIJY4yUre7rBbwwCAlOSXwY=; b=EHFuyzGU7spxwxMt9nIuVw6WrQ6qJPrptSnXd9BJznjuNaIB6+rCmpZU/lwJirn7dT WivGm1TEGryBBCz39TWkgYCG0HygRhC+4p3kqbzl/ia5gX7Cv8rbkIJyzxkw8kjNMisu Pmpoj6nKH/4ONwGmLZnCnaNTRHOdSODUCn7S6neb/vBhMHkGVDhHTLTTaeNjx133IhWi 7r+62qdoBO/xFOql7fgeqNCc5hHNg+Fvl6ZF70L2GpN9M0xs40PNiLVM+IVJ4XZ3kRYz QYqEIG1mFKBIgjvyjdhfAdkKfYmI5BFNtw7DNP4sycNkOnhb9cL0H+Evlp2cen7KyIsi uRcA== X-Gm-Message-State: APjAAAWkpdEd+a5SQGy8FGdvxE1DCenhazMPZlQwWOOSISWnaa2NPGm+ WehCu3a94nHkIzy08MhmiL5odA== X-Google-Smtp-Source: AHgI3IZ4HquIVdw3FSdjooAXDXvGGkFXaDcacP9cGgZwou9bpZA2GoCiYgr4tHUuhXiK1NkNgRj5yw== X-Received: by 2002:ac8:3ffd:: with SMTP id v58mr6364548qtk.220.1551363969216; Thu, 28 Feb 2019 06:26:09 -0800 (PST) Received: from redhat.com (pool-173-76-246-42.bstnma.fios.verizon.net. [173.76.246.42]) by smtp.gmail.com with ESMTPSA id j9sm9903684qtb.30.2019.02.28.06.26.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Feb 2019 06:26:08 -0800 (PST) Date: Thu, 28 Feb 2019 09:26:06 -0500 From: "Michael S. Tsirkin" To: si-wei liu Cc: "Samudrala, Sridhar" , Siwei Liu , Jiri Pirko , Stephen Hemminger , David Miller , Netdev , virtualization@lists.linux-foundation.org, virtio-dev , "Brandeburg, Jesse" , Alexander Duyck , Jakub Kicinski , Jason Wang , liran.alon@oracle.com Subject: Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework) Message-ID: <20190228091119-mutt-send-email-mst@kernel.org> References: <20190222100753-mutt-send-email-mst@kernel.org> <20190225210529-mutt-send-email-mst@kernel.org> <20190227173710-mutt-send-email-mst@kernel.org> <20190227184601-mutt-send-email-mst@kernel.org> <20190227193923-mutt-send-email-mst@kernel.org> <36901346-e3d5-4e51-6a8d-678eb5b9e352@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36901346-e3d5-4e51-6a8d-678eb5b9e352@oracle.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Feb 28, 2019 at 01:32:12AM -0800, si-wei liu wrote: > > > Will the > > > change break userspace further? > > > > > > -Siwei > > Didn't you show userspace is already broken. You can't "further > > break it", rename already fails. > It's a race, userspace tends to give slave a user(space) desired name but > sometimes may fail due to this race. Today if failover master is not up, > rename would succeed anyway. While what you proposed prohibits user from > providing a name in all circumstances if I understand you correctly. That's > what I meant of breaking userspace further. On the other hand, you seem to > tighten the kernel default naming to udev predictable names, which is > derived from only recent systemd-udevd, while there exists many possible > userspace naming schemes out of that. Users today who deliberately chooses > to disable predictable naming (net.ifnames=0 biosdevname=0) and fall back to > kernel provided names would expect the ethX pattern, with this change > admin/user scripts which matches the ethX pattern could potentially break. Whatever crashes with a name not matching ethX will crash on the standby interface *anyway*. So I think what you are saying is that someone might have already written scripts and gotten them to work on v4.17 when STANDBY was included and these scripts rely on ethX. Now these scripts will break. Maybe it is still early enough (just half a year passed) that the number of these users would be small. So how about a kernel config option and maybe a module parameter to rename the primary? People can then opt in to the old broken behaviour. -- MST