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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED 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 1BF13C43381 for ; Fri, 22 Feb 2019 03:33:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D3A2E20818 for ; Fri, 22 Feb 2019 03:33:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="HjW3QXTr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726298AbfBVDdu (ORCPT ); Thu, 21 Feb 2019 22:33:50 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:44932 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfBVDdu (ORCPT ); Thu, 21 Feb 2019 22:33:50 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1M3XeBl037359; Fri, 22 Feb 2019 03:33:40 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=u5JI8xCpndxFgP/L+i7VZz9zCH/df2lmYsy8bAb+UpI=; b=HjW3QXTrKMczV+sq3HZ06KpBuWzvvg/ODYuMDVOi2JcpjFkIXkNNAYBEYihYBArATGHv jwo+h3xRWAqRjyHBa5HPVRsZ2zbNv2JXlEbkWPv2nzRsLNQWonDHUEtRTmEkgyHxACyt VidK/uBA9qA1NMmxFGbqmMwuYfWhK9LmoR9eUEsPMQuCm4Pl1sen39nw89lRQD1zvEhA Du/wEYF5xmHTmcrz47a4seplB1/zhoZZLfrwGeUysppSTo3qGR2srhwFRijjCMmTM7uN UfZldPgqRWu8/11H1CEbg/QXobNkGmQGHEhuJjXxtpL/EDywERIyw7iAUit82PKcrGej +g== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2qp9xuc259-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Feb 2019 03:33:40 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1M3XcMp020009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Feb 2019 03:33:39 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1M3Xatt007146; Fri, 22 Feb 2019 03:33:37 GMT Received: from [192.168.0.18] (/76.102.100.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Feb 2019 19:33:36 -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" , Siwei Liu References: <1523386790-12396-1-git-send-email-sridhar.samudrala@intel.com> <1523386790-12396-5-git-send-email-sridhar.samudrala@intel.com> <20180410142608.50f15b45@xeon-e3> <20180411075334.GK2028@nanopsycho> <20190221203808-mutt-send-email-mst@kernel.org> Cc: Jiri Pirko , Stephen Hemminger , Sridhar Samudrala , 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: <581e4399-3969-aecd-e923-03bbc0880733@oracle.com> Date: Thu, 21 Feb 2019 19:33:23 -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: <20190221203808-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=9174 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 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-1902220022 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote: > On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote: >> Sorry for replying to this ancient thread. There was some remaining >> issue that I don't think the initial net_failover patch got addressed >> cleanly, see: >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268 >> >> The renaming of 'eth0' to 'ens4' fails because the udev userspace was >> not specifically writtten for such kernel automatic enslavement. >> Specifically, if it is a bond or team, the slave would typically get >> renamed *before* virtual device gets created, that's what udev can >> control (without getting netdev opened early by the other part of >> kernel) and other userspace components for e.g. initramfs, >> init-scripts can coordinate well in between. The in-kernel >> auto-enslavement of net_failover breaks this userspace convention, >> which don't provides a solution if user care about consistent naming >> on the slave netdevs specifically. >> >> Previously this issue had been specifically called out when IFF_HIDDEN >> and the 1-netdev was proposed, but no one gives out a solution to this >> problem ever since. Please share your mind how to proceed and solve >> this userspace issue if netdev does not welcome a 1-netdev model. > Above says: > > there's no motivation in the systemd/udevd community at > this point to refactor the rename logic and make it work well with > 3-netdev. > > What would the fix be? Skip slave devices? > There's nothing user can get if just skipping slave devices - the name is still unchanged and unpredictable e.g. eth0, or eth1 the next reboot, while the rest may conform to the naming scheme (ens3 and such). There's no way one can fix this in userspace alone - when the failover is created the enslaved netdev was opened by the kernel earlier than the userspace is made aware of, and there's no negotiation protocol for kernel to know when userspace has done initial renaming of the interface. I would expect netdev list should at least provide the direction in general for how this can be solved... -Siwei From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5492-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 92C6F9860E5 for ; Fri, 22 Feb 2019 03:33:46 +0000 (UTC) References: <1523386790-12396-1-git-send-email-sridhar.samudrala@intel.com> <1523386790-12396-5-git-send-email-sridhar.samudrala@intel.com> <20180410142608.50f15b45@xeon-e3> <20180411075334.GK2028@nanopsycho> <20190221203808-mutt-send-email-mst@kernel.org> From: si-wei liu Message-ID: <581e4399-3969-aecd-e923-03bbc0880733@oracle.com> Date: Thu, 21 Feb 2019 19:33:23 -0800 MIME-Version: 1.0 In-Reply-To: <20190221203808-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" , Siwei Liu Cc: Jiri Pirko , Stephen Hemminger , Sridhar Samudrala , 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 2/21/2019 5:39 PM, Michael S. Tsirkin wrote: > On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote: >> Sorry for replying to this ancient thread. There was some remaining >> issue that I don't think the initial net_failover patch got addressed >> cleanly, see: >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268 >> >> The renaming of 'eth0' to 'ens4' fails because the udev userspace was >> not specifically writtten for such kernel automatic enslavement. >> Specifically, if it is a bond or team, the slave would typically get >> renamed *before* virtual device gets created, that's what udev can >> control (without getting netdev opened early by the other part of >> kernel) and other userspace components for e.g. initramfs, >> init-scripts can coordinate well in between. The in-kernel >> auto-enslavement of net_failover breaks this userspace convention, >> which don't provides a solution if user care about consistent naming >> on the slave netdevs specifically. >> >> Previously this issue had been specifically called out when IFF_HIDDEN >> and the 1-netdev was proposed, but no one gives out a solution to this >> problem ever since. Please share your mind how to proceed and solve >> this userspace issue if netdev does not welcome a 1-netdev model. > Above says: > > there's no motivation in the systemd/udevd community at > this point to refactor the rename logic and make it work well with > 3-netdev. > > What would the fix be? Skip slave devices? > There's nothing user can get if just skipping slave devices - the name is still unchanged and unpredictable e.g. eth0, or eth1 the next reboot, while the rest may conform to the naming scheme (ens3 and such). There's no way one can fix this in userspace alone - when the failover is created the enslaved netdev was opened by the kernel earlier than the userspace is made aware of, and there's no negotiation protocol for kernel to know when userspace has done initial renaming of the interface. I would expect netdev list should at least provide the direction in general for how this can be solved... -Siwei --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org