From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1842CA0C4C for ; Tue, 23 Nov 2021 17:51:42 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D14D4003C; Tue, 23 Nov 2021 17:51:42 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 698484003C; Tue, 23 Nov 2021 17:51:40 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10177"; a="321293509" X-IronPort-AV: E=Sophos;i="5.87,258,1631602800"; d="scan'208";a="321293509" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2021 08:51:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,258,1631602800"; d="scan'208";a="571118871" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga004.fm.intel.com with ESMTP; 23 Nov 2021 08:51:39 -0800 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 23 Nov 2021 08:51:39 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 23 Nov 2021 08:51:38 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 23 Nov 2021 08:51:38 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 23 Nov 2021 08:51:36 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GSqsVf+ZgAEH/hf7/ySrPkt548BFliIByXtihdcC699Woq2nvot+tluC0501K8wIvXH7Uh61od0twkIyARdYOxm4gM8qbQm3I/Ug/T1J38WVaKoHIQqyFurb8vm80sYL4z8kdxOtad3hy4AB0p2WVoPzSIWOAh92tyZXoYnm3F/uGo4TmFAhhJzylJDRDum4lNO5cwefpLqmuGRNdzT5uQOUPycjnyjp5dUefRIvFk1Pk+VYppYQEQ3xau8jxNNXCaFRXNOxiLgn4tXremvDJiFoM8OdsGxU9U/QZVLJ+XvPbxr085Z4dj3Qkqu04HiGyIX28AlNIjXby31bh+gCrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=baWVvrCa+6dg7UFm3RJhhKTnPFFZCwJgOzjqh803Uks=; b=DO4GutpSw0AsdRwPcgfetTs9EFFzUiGLIqnqU2tp2TV35lZ0Iq1mCtRwFdekAcIcSTlJK+wIbCMC+n1WliPp+emjV8eQibmoOtPHA3/J9lM6OZ2QoYtOlr3xk2MiQv1J5e8CJ1UO+14mETKgG41jEFqIF32XACkkoac2FAb/YWABvRtS7ED6dovLqXkHbEj9J+7LuYgd8//XxkKxkZYr+TBBj4ndwPy6QtY8SiQcf/7OO/Y6eyx5KhQN2T/tw0TiH9yL3h1C2p2r4WEKGeVwOsN4e5QwkRJI+Ii5oNBCbs8tB4Hc1eOkZx7/sSJGDuCZWV4O7f7ceJZ2jp9AXIWHOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=baWVvrCa+6dg7UFm3RJhhKTnPFFZCwJgOzjqh803Uks=; b=g+TOl5SGUXOHL3tzE8ReKUAr0Qf2nGUvF+ZZwTSqobzHiOJn01W39Q3CEcdb3utwMLqI4EDiyHLZyAOXGqwZOCIRK9ElkVgLJSXODpKQY5klBvxPovFXkFiYLt2ItK0vSMO3ZqxK+nug7ZEQb/r3C/KfF6fs1pKhtZHTPPEKOv0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5143.namprd11.prod.outlook.com (2603:10b6:510:3f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.26; Tue, 23 Nov 2021 16:51:34 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bc5f:31a7:10ad:443c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bc5f:31a7:10ad:443c%5]) with mapi id 15.20.4690.028; Tue, 23 Nov 2021 16:51:33 +0000 Message-ID: <0914b58e-de54-50ef-7e48-febf9688eb09@intel.com> Date: Tue, 23 Nov 2021 16:51:27 +0000 Content-Language: en-US To: Stephen Hemminger CC: Thomas Monjalon , David Marchand , Elad Nachman , , , Igor Ryzhov , Eric Christian References: <20211008235830.127167-1-ferruh.yigit@intel.com> <20211008190335.1fdc8f4a@hermes.local> <20211123082218.11b894b0@hermes.local> From: Ferruh Yigit Subject: Re: [PATCH] kni: restrict bifurcated device support X-User: ferruhy In-Reply-To: <20211123082218.11b894b0@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DB9PR02CA0002.eurprd02.prod.outlook.com (2603:10a6:10:1d9::7) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB9PR02CA0002.eurprd02.prod.outlook.com (2603:10a6:10:1d9::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20 via Frontend Transport; Tue, 23 Nov 2021 16:51:32 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fed980b8-feef-4a0b-02ed-08d9aea18188 X-MS-TrafficTypeDiagnostic: PH0PR11MB5143: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: i1hm89+IeeOANXhkDsatB14aj/SY7Yg/SU3dSZJeM7tC6o1hs8z4myQBvh+vZdGz80jTSmCk+HhTPKyNFgANWjoTybOqGeUs1vguskxBFMOQk7iWdMaiVBJga+U4qAiarHT3KtAdFlrjsyq15oTOGb/uKd8hpNLCB2FzWRiIvQqkDk+8I6hryl2IMOQPLwHcvRMq7VpSYQ+gwFyfLuVBaC3yc1fC+bmkfFyN9M+b0vBk4bRA9p3FIJoo7ssuJhxUjtBiFpWQH3199Pb8LcViyU1DZ8p2WXohdgOY8dnIRotcSv+Nyu3z1gn5kLXHzqVDzNVaVUuP/WmoFqH0XmRE/snAH26l2dFi5AivwvsotD3xxYqiHjbD1lkcz07lqgO+7xlUmXAtcZYEFP49ZAuGQsb+G/1iRTEmjUSxLu9GZiOlftaB7D/tpWQlqVQWqdxqAjLzUgjrNc0ZKs/UXRfBLjFGP6WqyE/l8fS+lZiPQ5/PyzM59GlBRlzgcxGynt+cUSf9LnZhlAsXu4qJf7InSDgVFl3ec8VhLlbA0t9C6WGfJu0hI4phqfLqQ3I0t+M0oei5391BYeqbaGs4wkxa/9E+jxrrIa6yrNJHhhYIhl2ZNlsL/g7uKe+A1ZPJHKBUvbHLdcBh10WJZk0Vzh453cMTlVf3GH6/0GXXTt1flnS4aIKIrs+Gow85ApylWEzzDw4QbgiZk4sMMSJ/947qzBrcFQGgKLqkvpihdBWRjCT7EMQ8ex8p/DVUqH+Ma+QRfDr9REN6hjq72VNjcbyluoa+ArrWfyT8ZQNF/bI5VeA= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(186003)(8676002)(6666004)(2906002)(31686004)(82960400001)(38100700002)(53546011)(316002)(66946007)(8936002)(54906003)(66476007)(66556008)(5660300002)(31696002)(26005)(16576012)(956004)(36756003)(4326008)(2616005)(86362001)(83380400001)(966005)(6486002)(44832011)(6916009)(508600001)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TWRqTTdMSHlIVzJ4YnNvZlEva3YrV25MK1JVek5peHd3Z205Nm9lWVV5TmN5?= =?utf-8?B?KzVHTTJxSEhPQ25UM0tub2Fjc1RIUkJaMGRLemw1UjlNYmZzRllLOE1zbDhh?= =?utf-8?B?UDFuUEZ1bjh0Qmc0OEZXSWZrVkRKdzB4RFBSWmc5MW01Q3diN1FjZGxGWHFs?= =?utf-8?B?Ri9HSnE4MkJ2TEFnVUt4bjd0QzVYa0lKVWNNSUNXTXhsWklqbEw0eTlmb0Z0?= =?utf-8?B?L0xHMG5mVWE0MUJaZDZOeHp5djVtUE5CRnZJVXlJZnFFU0hIY1puSEo2cXJZ?= =?utf-8?B?dE9PVVVLRWdCVG5ETHFSMmhsdzUwM0xhSlFaTmlCUUc5K3VFckdhNk5rYXRu?= =?utf-8?B?aUFabGxBdzVDc2VsbTN3RVdxUzBFdERpYzBDOUIxT3pwWHJxMUpjblZBbktU?= =?utf-8?B?NHVuRlhjdjlDY2lNYjk5RXNKaUM5ajVxZlg4UmxVWFVXMTVtZ1MrZFhrOHJz?= =?utf-8?B?VENra1EveGRkMi8vNUlrZUNZQzFLOXRpYkpwNDNoS2VxbnpLamhkUGhrYTRi?= =?utf-8?B?Y1p5aFlpdU96T1NNV2VBSFN5Ti8xbzVPZlBWWG1JcjZvYUdVSG1TMTNwTlJv?= =?utf-8?B?cGNTenUwbnF1TGJWSnJzOEpCTTZoYzhYTXh6aUhScll6OVNGK29qWnZJZWly?= =?utf-8?B?UG9Hb3hwL05tT3R3alo4aUVFbkxKVldLdHR1YzV4WFZIbHMzL3JKK3c3andN?= =?utf-8?B?VUZ1TFJvOEQ1SG04MElCcERNMEJKYVo5S1d3TVZzd0hVQUFqOTA4UTFTVnJI?= =?utf-8?B?U1hTUFFMOEwvZnkvQVZLdFN0QnliSTNHMjNDbEhBS1NOV2N3QmE1aCtQS0Yv?= =?utf-8?B?N0NtTjA4T3NTUDlvN0svNmUwNnJvN1Fua2xUL0xvVnhxRlFvK0lzM0V6TmhU?= =?utf-8?B?WCs1bnBqMkZ4QXczbmxpZU15SUtPTGhMdVltdmpudm45Mnk3R1FjbzJZVjFR?= =?utf-8?B?ckR2LzEwTGROVkZMazdXVnRScmV2UkR2TlgvRjhPMkc2dmY2NFNrMlg1ZW94?= =?utf-8?B?a2pnd3JjdFlmbmpwRHJtMWhCeEV3MEFwRUcxdUhtK3NqdSs2bVBXeWhscm9F?= =?utf-8?B?Z1pad2txdDMzMEswd0NsdDZnMk5NTEx5UEY1dVZuclZpc3FVT2hhU0NFL0xS?= =?utf-8?B?WWlUQnhwM3VsT255SzBzOTlyTk9seHhTTldvUDhvYXNacHNBem9qc1g5Zmxk?= =?utf-8?B?OHFGUHBCR3lGKzRBdTR1SkEzeE54dWlWQ00zWEdsSkxWTkhrTXQ2MlVDeCt6?= =?utf-8?B?bmtsWWJhZkZoSUdHN0c1SVhheWRKd1ZPelpQWC95cVhYTEo5R0lJUXFYUmZr?= =?utf-8?B?TDEyZnNoRnVncjhqbTRUSFViSnNoWEhDeStwK0JLRXI3TlVaQWJ5d0lZbmor?= =?utf-8?B?TVkyQTBqVHp5T2xxSGo4aU1UZWp1d2xKeUtWUk9xWjV1VE1sVzhxeFZ0OVFR?= =?utf-8?B?dmdjQzdJZUpMZFBtN1BJcytPa3hWM1pxSlV3Y21mR3BtSUNEV1ZiWVkvMmFU?= =?utf-8?B?UXpORW1hS3crRUswRnV6RnVEMm1RT2laL0NDVmgxMzJHakF2SHZPTnlSeXQ1?= =?utf-8?B?MENtckxBdzhUcFI1V2krbGVsQmU4TVVISDVGWmZSM01DUHNIdEcxTWlRczRI?= =?utf-8?B?TDVydDk3b1d6K1RkNjM2UURiVWRiZXFjV0dHdDYvTU1aWEpTOW1qYmVQM3ly?= =?utf-8?B?NWRKSUczeXRYQ3lka05BK2dXdkQ4RU1FclVsM0JHeUZ4STZnNHJacGttbFhL?= =?utf-8?B?bmZ5TUhGQjRTczVPVDgxUkd4eVo0aVR5Wm1OVjJWUmZTVWJYWEpRWWZzWXI0?= =?utf-8?B?OXpOK3BNalJacHJubTJDS0Jkc2hJQkNQN3JBNFNyMWw1dGpYRnFXUjZILzVG?= =?utf-8?B?clppcG9rczNEUTF3WGRmYkZ0TzE2ejhLOTJKT0hMNnJFNzlQQmMwMUJOeGdC?= =?utf-8?B?UDRHbDRLeUJpV0VVQ3UrTnJGR0U3bHV1cFc1dGc5OUY4MVdYeG5IUmk0Vklj?= =?utf-8?B?ei9pQnZHeHJ6UXFaVVFaZEVjZ0FpUXJHOUM5QzMxUkJuUktNTTJnVnNwaTA4?= =?utf-8?B?YlBlZlBNM3Z0NWxIelFuY0lJa1pBWDZIQm5Cbk1MdFZLL2d2UVN2MTNFNUJx?= =?utf-8?B?SUhVMllCY0RoUzdWSmd1aWMzSG9qb1Z6YUQ3Z25XMWdyTmxFWEhXd2FycDk3?= =?utf-8?Q?YNrFCezSkuSb0aFMOaIfkEM=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: fed980b8-feef-4a0b-02ed-08d9aea18188 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2021 16:51:33.8117 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Ueno0edP1vdmCIeherYdxt268IjoHIEY1LH2fXnBF0SRejvQTzC8IvKV6g4yi6MpR3JUqjSOmpUElizMSyyzHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5143 X-OriginatorOrg: intel.com X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On 11/23/2021 4:22 PM, Stephen Hemminger wrote: > On Tue, 23 Nov 2021 09:54:01 +0000 > Ferruh Yigit wrote: > >> On 10/9/2021 3:03 AM, Stephen Hemminger wrote: >>> On Sat, 9 Oct 2021 00:58:30 +0100 >>> Ferruh Yigit wrote: >>> >>>> To enable bifurcated device support, rtnl_lock is released before calling >>>> userspace callbacks and asynchronous requests are enabled. >>>> >>>> But these changes caused more issues, like bug #809, #816. To reduce the >>>> scope of the problems, the bifurcated device support related changes are >>>> only enabled when it is requested explicitly with new 'enable_bifurcated' >>>> module parameter. >>>> And bifurcated device support is disabled by default. >>>> >>>> So the bifurcated device related problems are isolated and they can be >>>> fixed without impacting all use cases. >>>> >>>> Bugzilla ID: 816 >>>> Fixes: 631217c76135 ("kni: fix kernel deadlock with bifurcated device") >>>> Cc: stable@dpdk.org >>>> >>>> Signed-off-by: Ferruh Yigit >>> >>> Calling userspace with semaphore held is still risky and buggy. >>> There is no guarantee that the userspace DPDK application will be well behaved. >>> And if it is not, the spinning holding RTNL would break any other network management >>> functions in the kernel. >>> >> >> Hi Stephen, >> >> Because of what you described above, we tried the option that releases the RTNL >> lock before userspace callback, >> That caused a deadlock in the ifdown, and we add a workaround for it. >> >> But now we are facing with two more issues because of the rtnl lock release, >> - Bugzilla ID: 816, MAC set cause kernel deadlock >> - Some requests are overwritten (because of the workaround we put for ifdown) >> >> This patch just converts the default behavior to what it was previously. >> Releasing rtnl lock still supported with the module param, but I think it >> is not good idea to make it default while it is know that it is buggy. >> >> @Thomas, @David, >> Can it be possible to get this patch for -rc4? Since it has potential >> to cause a deadlock in kernel as it is. >> >> I can send a new version with documentation update. > > Is it possible for userspace to choose the correct behavior instead > of module option. Users will do it wrong. > That is why default is changed. If user will use bifurcated driver, user will know it and need to explicitly request this support. I don't think there is a way to know automatically which device/interface will be used with KNI, that is why user config is required. Right now KNI is with a defect that can cause a deadlock in the kernel with its default config, that is why I think we should get this fix first for the release. > >> >>> These are the kind of problems that make me think it there should be a >>> big "DO NOT USE THIS" onto KNI. Maybe make it print a big nasty message >>> (see kernel VFIO without IOMMU description) or mark kernel as tainted?? >>> >>> See: https://fedoraproject.org/wiki/KernelStagingPolicy >>> >>> Something like: >>> >>> diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c >>> index 611719b5ee27..d47fc6133cbe 100644 >>> --- a/kernel/linux/kni/kni_net.c >>> +++ b/kernel/linux/kni/kni_net.c >>> @@ -838,6 +838,14 @@ kni_net_init(struct net_device *dev) >>> dev->header_ops = &kni_net_header_ops; >>> dev->ethtool_ops = &kni_net_ethtool_ops; >>> dev->watchdog_timeo = WD_TIMEOUT; >>> + >>> + /* >>> + * KNI is unsafe since it requires calling userspace to do >>> + * control operations. And the overall quality according to >>> + * kernel standards is the same as devices in staging. >>> + */ >>> + add_taint(TAINT_CRAP, LOCKDEP_STILL_OK); >>> + netdev_warn(dev, "Adding kernel taint for KNI because it is not safe\n"); >> >> I am for discussing above separate from this patch, since this patch >> restores the behavior that exist since KNI module exists. > > Any user of KNI will already get tainted because KNI is out of tree driver. > I mean the note and explicit 'add_taint()' you mentioned above, can we separate it from this bug fix.