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 10410C43381 for ; Fri, 1 Mar 2019 20:55:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BCA1E20848 for ; Fri, 1 Mar 2019 20:55:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="kGtiLAj8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726002AbfCAUzZ (ORCPT ); Fri, 1 Mar 2019 15:55:25 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:51224 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725905AbfCAUzZ (ORCPT ); Fri, 1 Mar 2019 15:55:25 -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 x21KrsdF013645; Fri, 1 Mar 2019 20:55:10 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=/3rPA19bf6Y4ijlTsKjzdcoKScPjkQ7s3xHxDmm//3k=; b=kGtiLAj8kNekbooCE36344PNHIqWZcJBGprMI4rwusllnzqGBEi8Q+QM8fObjpnXGEG9 wB/v4BzkYplcXRBhXf3qEekglMg8i8emHqxE/wlEjCCQvrofSK+7yr1CrfcO6EgwP0Uk jxKt6oyBw7F92pHVD/919v2+ry4Po2XfZVZSwY7J+Qq3Y49CTyewcCl2foUwVB13ZFiA F8g5eMx5zhdwAmnL3eEdx/Wk8ATAwdmdcSC0gS+q4YWOnJ7UMF7YU71RTDSMxq8pkDQs VphwhXH3eLj8/lk9gG4Bryjd0eWdBx8hT61oRaiN+VJkN1+susIvwKwpR+j6J6DzMVgN Jg== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2qtupesqub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Mar 2019 20:55:10 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x21Kt9Sp008291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Mar 2019 20:55:09 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x21Kt708021643; Fri, 1 Mar 2019 20:55:07 GMT Received: from [10.159.252.150] (/10.159.252.150) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Mar 2019 12:55:06 -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: <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> <8a387954-1e21-947b-a5a9-c49adaea2e81@oracle.com> <20190301082448-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: <32dbd963-b4ca-5f05-3259-89594c55e911@oracle.com> Date: Fri, 1 Mar 2019 12:55:02 -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: <20190301082448-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=9182 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-1903010142 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/1/2019 5:27 AM, Michael S. Tsirkin wrote: > On Thu, Feb 28, 2019 at 05:30:56PM -0800, si-wei liu wrote: >> >> 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. > Well that's special code for failover already. So far we just > taught userspace to skip renaming slave interfaces. I think today kernel provided names never collapse, e.g. master gets eth0 then standby will get eth1. It's the userspace specified name that suffers name clashing, mostly the default predictable naming pattern from systemd-udevd. Kernel should not assume there's only one naming pattern in userspace. Users can customize naming with udev rules in /etc which do not conform to the default udevd pattern at all. It's pretty legitimate use case. > >>> 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. > No what I say is that they will crash on rename of standby too. What do you mean crashing on standby rename? First off, if master is not up, rename on both standby and primary should not fail. If master is up, the standby should be named before userspace brings up the master, so what's the issue you talked about? Thanks, -Siwei > >> 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 >> From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5559-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B174E985E13 for ; Fri, 1 Mar 2019 20:55:20 +0000 (UTC) References: <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> <8a387954-1e21-947b-a5a9-c49adaea2e81@oracle.com> <20190301082448-mutt-send-email-mst@kernel.org> From: si-wei liu Message-ID: <32dbd963-b4ca-5f05-3259-89594c55e911@oracle.com> Date: Fri, 1 Mar 2019 12:55:02 -0800 MIME-Version: 1.0 In-Reply-To: <20190301082448-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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" 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 List-ID: On 3/1/2019 5:27 AM, Michael S. Tsirkin wrote: > On Thu, Feb 28, 2019 at 05:30:56PM -0800, si-wei liu wrote: >> >> 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. > Well that's special code for failover already. So far we just > taught userspace to skip renaming slave interfaces. I think today kernel provided names never collapse, e.g. master gets eth0 then standby will get eth1. It's the userspace specified name that suffers name clashing, mostly the default predictable naming pattern from systemd-udevd. Kernel should not assume there's only one naming pattern in userspace. Users can customize naming with udev rules in /etc which do not conform to the default udevd pattern at all. It's pretty legitimate use case. > >>> 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. > No what I say is that they will crash on rename of standby too. What do you mean crashing on standby rename? First off, if master is not up, rename on both standby and primary should not fail. If master is up, the standby should be named before userspace brings up the master, so what's the issue you talked about? Thanks, -Siwei > >> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org