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 7142CC43381 for ; Wed, 6 Mar 2019 07:15:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3FF0F206DD for ; Wed, 6 Mar 2019 07:15:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="QUfSGAIO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729395AbfCFHPZ (ORCPT ); Wed, 6 Mar 2019 02:15:25 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:47526 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729275AbfCFHPY (ORCPT ); Wed, 6 Mar 2019 02:15:24 -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 x267Exja051382; Wed, 6 Mar 2019 07:15:14 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=m5crwVIYAVoRwtPfwng+44HI6XB+9qsncd3VzWn62Iw=; b=QUfSGAIO1jkLgzj+SRKyCnXoI/7Hf5B144K5FXycquOEHzD5KpoyPh22n72YtJpM6xEJ BvS7aRSD25XtZAiZX84OQ1AV37tB90yqkasaPiu2uwhmpXzksFnKbzn988KsNNtMrNZS j2iXW8EgOI+BTSMlnBCywBStE9Gd46/D0fu+0ixkdWf1FhpomYdt8rO5VculQzHgv87P 8JaDXTJKvL3sGawYwmPqU5VJnYgc0ywSsREM1XVflr2kXBl+K5IxLG7XSpZK28n+QZKJ 4vxWpko4Iim310w0JadeYdKvhTvs8cea595je4cVMQS0PDlgU/sQClXRbzPca1K1uTJk sw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2qyh8ua0es-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 06 Mar 2019 07:15:13 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x267FCRa026054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Mar 2019 07:15:13 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x267FBdG029796; Wed, 6 Mar 2019 07:15:11 GMT Received: from [192.168.0.18] (/76.102.100.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Mar 2019 23:15:10 -0800 Subject: Re: [RFC PATCH net-next] failover: allow name change on IFF_UP slave interfaces To: "Michael S. Tsirkin" References: <1551747059-11831-1-git-send-email-si-wei.liu@oracle.com> <20190304213032-mutt-send-email-mst@kernel.org> <20190305112427.1a23822e@shemminger-XPS-13-9360> <9448ae8f-c4e0-58a4-ff46-2f2951113d1e@oracle.com> <20190305190325-mutt-send-email-mst@kernel.org> <8737e985-f418-7002-c8b5-0023d1c4a453@oracle.com> <20190305193439-mutt-send-email-mst@kernel.org> <20190306013255-mutt-send-email-mst@kernel.org> Cc: Stephen Hemminger , Sridhar Samudrala , Jakub Kicinski , Jiri Pirko , David Miller , Netdev , 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: <98243a73-a42a-6465-cf3c-a049c53b4d0c@oracle.com> Date: Tue, 5 Mar 2019 23:15:06 -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: <20190306013255-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=9186 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-1903060050 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/5/2019 10:43 PM, Michael S. Tsirkin wrote: > On Tue, Mar 05, 2019 at 04:51:00PM -0800, si-wei liu wrote: >> >> On 3/5/2019 4:36 PM, Michael S. Tsirkin wrote: >>> On Tue, Mar 05, 2019 at 04:20:50PM -0800, si-wei liu wrote: >>>> On 3/5/2019 4:06 PM, Michael S. Tsirkin wrote: >>>>> On Tue, Mar 05, 2019 at 11:35:50AM -0800, si-wei liu wrote: >>>>>> On 3/5/2019 11:24 AM, Stephen Hemminger wrote: >>>>>>> On Tue, 5 Mar 2019 11:19:32 -0800 >>>>>>> si-wei liu wrote: >>>>>>> >>>>>>>>> I have a vague idea: would it work to *not* set >>>>>>>>> IFF_UP on slave devices at all? >>>>>>>> Hmm, I ever thought about this option, and it appears this solution is >>>>>>>> more invasive than required to convert existing scripts, despite the >>>>>>>> controversy of introducing internal netdev state to differentiate user >>>>>>>> visible state. Either we disallow slave to be brought up by user, or to >>>>>>>> not set IFF_UP flag but instead use the internal one, could end up with >>>>>>>> substantial behavioral change that breaks scripts. Consider any admin >>>>>>>> script that does `ip link set dev ... up' successfully just assumes the >>>>>>>> link is up and subsequent operation can be done as usual. >>>>> How would it work when carrier is off? >>>>> >>>>>> While it *may* >>>>>>>> work for dracut (yet to be verified), I'm a bit concerned that there are >>>>>>>> more scripts to be converted than those that don't follow volatile >>>>>>>> failover slave names. It's technically doable, but may not worth the >>>>>>>> effort (in terms of porting existing scripts/apps). >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Siwei >>>>>>> Won't work for most devices. Many devices turn off PHY and link layer >>>>>>> if not IFF_UP >>>>>> True, that's what I said about introducing internal state for those driver >>>>>> and other kernel component. Very invasive change indeed. >>>>>> >>>>>> -Siwei >>>>> Well I did say it's vague. >>>>> How about hiding IFF_UP from dev_get_flags (and probably >>>>> __dev_change_flags)? >>>>> >>>> Any different? This has small footprint for the kernel change for sure, >>>> while the discrepancy is still there. Anyone who writes code for IFF_UP will >>>> not notice IFF_FAILOVER_SLAVE. >>>> >>>> Not to mention more userspace "fixup" work has to be done due to this >>>> change. >>>> >>>> -Siwei >>>> >>>> >>> Point is it's ok since most userspace should just ignore slaves >>> - hopefully it will just ignore it since it already >>> ignores interfaces that are down. >> Admin script thought the interface could be bright up and do further >> operations without checking the UP flag. > These scripts then would be broken on any box with multiple interfaces > since not all of these would have carrier. Consider a script executing `ifconfig ... up' and once succeeds runs tcpdump or some other command relying on UP interface. It's quite common that those scripts don't check the UP flag but instead just rely on the well-known fact that the command exits with 0 meaning the interface should be UP. This change might well break scripts of that kind. > > >> It doesn't look to be a reliable >> way of prohibit userspace from operating against slaves. >> >> -Siwei >> >> > This does not mean we shouldn't make an effort to disable broken > configurations. > > I am not arguing against your patch. Not at all. I see better > hiding of slaves as a separate enhancement. I understand, but my point is we should try to minimize unnecessary side impact to the current usage for whatever "hiding" effort we can make. It's hard to find a tradeoff sometimes. > > > Acked-by: Michael S. Tsirkin > > Thank you. -Siwei