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=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 88B61C43381 for ; Wed, 27 Mar 2019 22:31:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 51F2821738 for ; Wed, 27 Mar 2019 22:31:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="QCnomi7o" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728252AbfC0Wbu (ORCPT ); Wed, 27 Mar 2019 18:31:50 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:48958 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725601AbfC0Wbu (ORCPT ); Wed, 27 Mar 2019 18:31:50 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2RMT6nM103648; Wed, 27 Mar 2019 22:31:35 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=ZvgXw3wCMLhztVvuELpIxrDaMmB3JbMsFn68ky2KQH8=; b=QCnomi7ogAiNlximlq6E4Unc3byMYVzlUbDsKvhbD5ySaPKVRll9ES8S7cNpO+HMtkvQ MBiLz7392YxheDflm1cfIT+fYhSAOU3TtYKbFZDs4EFVNOcF8zmW/Od7ToQUHDBB3wI8 +42/jKE+PZLTKuBd8+rFX8LmUz4UuH0HZI9hkvpWqEPFEJRgCOR+J/o9Qn5WiKFbZZVA cq+iXZKd8+vjYu0PI2z6A0+uIUe62mVuFmXVUaX3b/nYawyLB/rKSTIz4iVz6kaF2E4O NRMwKa6zJvf9hrnoMRz3SDgQ+tjxfBxIB2wiq1GiqHGqiVeoihodR55MLZdQL1hPzBQz UQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2re6djkeed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Mar 2019 22:31:35 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2RMVOXm025482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Mar 2019 22:31:24 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2RMVNx0013451; Wed, 27 Mar 2019 22:31:23 GMT Received: from [10.159.236.24] (/10.159.236.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Mar 2019 15:31:23 -0700 Subject: Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces To: "Michael S. Tsirkin" References: <1553644093-10917-1-git-send-email-si-wei.liu@oracle.com> <20190326191342.11f0cb55@shemminger-XPS-13-9360> <20190327092424-mutt-send-email-mst@kernel.org> <20190327181433-mutt-send-email-mst@kernel.org> Cc: Stephen Hemminger , 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 From: si-wei liu Organization: Oracle Corporation Message-ID: <97fcde0d-4a2d-5dbf-b735-de07245e0c4b@oracle.com> Date: Wed, 27 Mar 2019 15:31:17 -0700 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: <20190327181433-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=9208 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=536 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903270154 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/27/2019 3:16 PM, Michael S. Tsirkin wrote: > On Wed, Mar 27, 2019 at 01:10:10PM -0700, si-wei liu wrote: >> Another less safer option is that we just notify userspace anyway without >> sending down/up event around, as I don't see *any real application* cares >> about the link state or whatsoever when it attempts to detect rename. > How do you write a race ree handler then? ATM just detecting link up is > sufficient and covers 100% of cases. Seems like a good idea to keep it > that way. > What do you mean? Which flag or attribute do you think 100% of the userspace regard it as link up? And why userspace that cares about name change needs to double check whether link is up or not? I'm sorry, but are you sure this is the 100% case that every userspace app does it like what you're claiming? -Siwei