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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 EB936C43381 for ; Fri, 1 Mar 2019 01:31:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AD5F62085A for ; Fri, 1 Mar 2019 01:31:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="dhdlXD+N" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731008AbfCABbN (ORCPT ); Thu, 28 Feb 2019 20:31:13 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:57522 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725896AbfCABbM (ORCPT ); Thu, 28 Feb 2019 20:31:12 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x211TZwg076933; Fri, 1 Mar 2019 01:31:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : cc : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=dOG//5xZKAIlkhgGj6JdTVpw/uAVRnJz4EiXNQ41pgY=; b=dhdlXD+NswSfVGRoAt3FUTaFwCQ0btoJCMtFLGapcQ+Fr6TahF91MgYtxbGd96lcPOKG RY9xQuPh1y9vKwNUlZ7Ref2J/c4cSbXW+XT2h8ngkYF4UzThxfM+mHSpHcOv0jl7QLRD SCahQkqBZ3m8k2bJKtuMGwjA8ZsIDSoR1k0R+Bi9VPVMjqD4Pn01RzGBtx7kLefwdDNl uqJNG6EdkGGEvWtYlAtnOKKaBABqXpTgK25VswU8SmCjrj7KclY9qKh9MjSFnJiWR42M k3ShjyfCVYbjQy/ziopO+uCCGIG0hF7NHfTiTE1ESFow9U6+FBLxv5QFzsL9LkEHsXl7 Og== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2qtupemva8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Mar 2019 01:31:02 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x211V2qD007744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Mar 2019 01:31:02 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x211V1AW012944; Fri, 1 Mar 2019 01:31:01 GMT Received: from [10.159.243.101] (/10.159.243.101) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2019 17:31:01 -0800 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) To: "Michael S. Tsirkin" 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> <20190228091119-mutt-send-email-mst@kernel.org> 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 From: si-wei liu Organization: Oracle Corporation Message-ID: <8a387954-1e21-947b-a5a9-c49adaea2e81@oracle.com> Date: Thu, 28 Feb 2019 17:30:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190228091119-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9181 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903010006 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/28/2019 6:26 AM, Michael S. Tsirkin wrote: > 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*. With udev predictable naming disabled they should not. It's not hard for user to look for device attribute to persistent the name well, in a consistent and reliable way. > > 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. The controversial part is the new kernel naming pattern. Initially I thought there shouldn't be such crazy scripts relying on the pattern, but when I worked on cloud-init it I realized that there's already a lot of software taking assumption around the 'eth0' name. In the past I've seen random scripts that parses the ethX name assumes (incorrectly) the name ends up with digits, or even the digits and name are 1:1 mapped. Of course, you can say these are bugs in scripts themselves. Anyway, I'll let others in the netdev to comment on this new scheme, maybe that's the concern of merely myself. The good part of your proposal is that we can get consistent slave name, which still plays its role until we move towards making slave names less relevant, i.e. ideally a 1-netdev model. I think we both agree that the master matters more than the slave names. > > 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. Were I could I would ask why a similar opt-in (kernel config or module parameter) couldn't be implemented to open up the rename restriction on slave, net_failover in particular. What I felt about this rename restriction was more because of historical reason than anything else, while net_failover is comparatively a new type of link that we are now designing proper use case it should support, and can get it shaped to whatever it fits. My personal view is that the slave can't be renamed when master is running is just implementation details that got incorrectly exposed to userspace apps for many years. It's old behavior with historical reason for sure, but I don't think this applies to net_failover. (FWIW as one previous bond maintainer for another OS, we relieved the rename restriction slaves 13 year ago, while no single complaint or issue was ever raised because of this change over the years, neither from the customers of tens of millions of installation base, nor the FOSS software running atop. Of course, Linux is different so that experience doesn't count.) Thanks, -Siwei