Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp1502828rdb; Tue, 30 Jan 2024 23:54:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IEqLARf3sMdK42wguB6MGxklDbZDwZkVPPbNqHGdlk9AoiIkOufSQ+71cZqsbHwwRZVd5gE X-Received: by 2002:a17:906:f855:b0:a35:c8ce:ca0f with SMTP id ks21-20020a170906f85500b00a35c8ceca0fmr565020ejb.24.1706687668319; Tue, 30 Jan 2024 23:54:28 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706687668; cv=pass; d=google.com; s=arc-20160816; b=Bp9MKVy2CuWJKvPMEPGL5qQHjnL+HbDMfcaiai2FdDjb9Na9MYajAYjk2okXhrECpq QiRdQ7Dm6XBSvZzfEd9j2+CeX1LqjtVj0JOBjtrKEKhR3+Mb2GSnw91rhMqXYiy2kcWa LqCqiqgx7NRKUuH07ZShOE3sYhj9zVISH+qnPHz+0DPMJnuuJID6qkakEihav9iWfWCt BqK0/U9thdl7XcaDuE72H4fqDECIgD0vSTm6pyvvvKJ7y7K7+8PeK0LrJjKEXeK5UWs+ 1uSVQcSpoawvIxE6Rtjyjpsv5LL/97Sc6C4Wv6PeYz94QwSjycqRH1EnkdYANchZcn9v dlUA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date:dkim-signature:dkim-filter; bh=7DgOp55USUCAv7zrw7ngdlEyvKDTOomQA+HSmXHyj7A=; fh=Ffx/os1V54gW+Ri5aky3II+UemPODsSKd2sXZYzec8o=; b=vSLpisjJO0lZEfT8hsglAgRHM262IAW0ajAd7lLjMJMR+sljO8mH4WpFPOa6n20tMY LlptLCKncDyKdDg/cll7cBtw9NJ9+hBK80m66xXNiSLmKQwG/nIcz8nIArohvxe6poHI FGhM+MILJ4bKXGhxYvWx6ZXqpX+R+Qnv+KKARxiylIozt1e9/C3TpA2Go4SS8uWWGMj4 14oMm4bZ4u0goMjNgnPzo06kBI335rha44uQe7EqoVb9Pv9olcLAJ9YTocSnm+Iwkfsc nRGAy2lsvNumKgraxsQvs0tAQ869izBlr8XWg9FOeKCFumIj4xRSer7iOQYZ0vgAY2/d H6IQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=gfXKsrrg; arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com); spf=pass (google.com: domain of linux-kernel+bounces-45955-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45955-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com X-Forwarded-Encrypted: i=1; AJvYcCWPraBFH6wDCbTG0B+YGNqQads2xG9+YarsJCsv8fU+8j/lDrLuZx9jAf8x2GJKJ4mOIBIBJ/eR6TW6tz47HCie41lA+cHlQS4YYBTKaA== Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id g2-20020a170906198200b00a2d4062fbcesi5051476ejd.989.2024.01.30.23.54.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 23:54:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-45955-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=gfXKsrrg; arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com); spf=pass (google.com: domain of linux-kernel+bounces-45955-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45955-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E3F091F220B5 for ; Wed, 31 Jan 2024 07:54:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E979356B9D; Wed, 31 Jan 2024 07:54:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="gfXKsrrg" Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6AC755B1FD; Wed, 31 Jan 2024 07:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706687650; cv=none; b=fF33IFaYH1o3z/a0zwfCQOC+PPv2T7wJ+xjVZ9NENSbrzqguNc3yuB6SxSowkFjb14TI05Z18nRRnDNxakjOeDQ0kAKyYpi82n48qOfGjqyivEKV+kMzLMhFjcHUSu/gnrcF/Rg4a23AiCPcvMj/dCTpgH8eM/IqGZV7CpuAnC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706687650; c=relaxed/simple; bh=m6C4Ku8bvmkbexxJOJ7sBnHQ+qywQOk01yROQJjxJrE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z8JV+BPbaSYUQIrWBaX/Brb3JtJryOqRCqjXUxAa85AztGifCH59xzLDjyM/RrYDciNH+A80QATgpX+pvnd0nlt6+wInS2FDM6hCOH9GABAt3cwKa0vwVNrZ7I6mVVX3/5x+Ru5tu4rlcxU1x5s+//Pemjtjb6qPyvvo3W069rQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=gfXKsrrg; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: by linux.microsoft.com (Postfix, from userid 1134) id BE57E20B2000; Tue, 30 Jan 2024 23:54:04 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com BE57E20B2000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1706687644; bh=7DgOp55USUCAv7zrw7ngdlEyvKDTOomQA+HSmXHyj7A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gfXKsrrgRkpo0YCzOcCl1PnELBK0m/Vgxdtv6pLH9mgn4Hy8r8xsiAUioe3Qb1U5S sDseMiQeaGw9F7S/iwBcz8NxDyjRm5Ih/iS65S8qI4xZsgiVxJBP94Vsq8ACZUmJbh CaP57jfT5YDpHZ8PT/0ls0aYwoL/rnArELGVh4+Y= Date: Tue, 30 Jan 2024 23:54:04 -0800 From: Shradha Gupta To: Dexuan Cui Cc: KY Srinivasan , Haiyang Zhang , Wei Liu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Wojciech Drewek , "linux-hyperv@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Shradha Gupta , "stable@vger.kernel.org" Subject: Re: [PATCH] hv_netvsc:Register VF in netvsc_probe if NET_DEVICE_REGISTER missed Message-ID: <20240131075404.GA18190@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1706599135-12651-1-git-send-email-shradhagupta@linux.microsoft.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) On Tue, Jan 30, 2024 at 08:13:21PM +0000, Dexuan Cui wrote: > > From: Shradha Gupta > > Sent: Monday, January 29, 2024 11:19 PM > > [...] > > If hv_netvsc driver is removed and reloaded, the NET_DEVICE_REGISTER > > s/removed/unloaded/ > unloaded looks more accurate to me :-) > > > [...] > > Tested-on: Ubuntu22 > > Testcases: LISA testsuites > > verify_reload_hyperv_modules, perf_tcp_ntttcp_sriov > IMO the 3 lines can be removed: this bug is not specific to Ubuntu, and the > test case names don't provide extra value to help understand the issue > here and they might cause more questions unnecessarily, e.g. what's LISA, > what exactly do the test cases do. > > > +/* Macros to define the context of vf registration */ > > +#define VF_REG_IN_PROBE 1 > > +#define VF_REG_IN_RECV_CBACK 2 > > I think VF_REG_IN_NOTIFIER is a better name? > RECV_CBALL looks inaccurate to me. > > > @@ -2205,8 +2209,11 @@ static int netvsc_vf_join(struct net_device > > *vf_netdev, > > ndev->name, ret); > > goto upper_link_failed; > > } > > - > > - schedule_delayed_work(&ndev_ctx->vf_takeover, > > VF_TAKEOVER_INT); > > + /* If this registration is called from probe context vf_takeover > > + * is taken care of later in probe itself. > I suspect "later in probe itself" is not accurate. > If 'context' is VF_REG_IN_PROBE, I suppose what happens here is: > after netvsc_probe() finishes, the netvsc interface becomes available, > so the user space will ifup it, and netvsc_open() will UP the VF interface, > and netvsc_netdev_event() is called for the VF with event == > NETDEV_POST_INIT (?) and NETDEV_CHANGE, and the data path is > switched to the VF. > > If my understanding is correct, I think in the case of 'context' == > VF_REG_IN_PROBE, I suspect the "Align MTU of VF with master" > and the "sync address list from ndev to VF" in __netvsc_vf_setup() are > omitted? If so, should this be fixed? e.g. Not sure if the below is an issue or not: > 1) a VF is bound to a NetVSC interface, and a user sets the MTUs to 1024. > 2) rmmod hv_netvsc > 3) modprobe hv_netvsc > 4) the netvsc interface uses MTU=1500 (the default), and the VF still uses 1024. > > > @@ -2597,6 +2604,34 @@ static int netvsc_probe(struct hv_device *dev, > > } > > > > list_add(&net_device_ctx->list, &netvsc_dev_list); > > + > > + /* When the hv_netvsc driver is removed and readded, the > > s/removed and readded/unloaded and reloaded/ > > > + * NET_DEVICE_REGISTER for the vf device is replayed before > > probe > > + * is complete. This is because register_netdevice_notifier() gets > > + * registered before vmbus_driver_register() so that callback func > > + * is set before probe and we don't miss events like > > NETDEV_POST_INIT > > + * So, in this section we try to register each matching > > Looks like there are spaces at the end of the line. We can move up a few words > from the next line :-) > > s/each matching/the matching/ > A NetVSC interface has only 1 matching VF device. > > > + * vf device that is present as a netdevice, knowing that it's register > > s/it's/its/ > > > + * call is not processed in the netvsc_netdev_notifier(as probing is > > + * progress and get_netvsc_byslot fails). > > + */ > > + for_each_netdev(dev_net(net), vf_netdev) { > > + if (vf_netdev->netdev_ops == &device_ops) > > + continue; > > + > > + if (vf_netdev->type != ARPHRD_ETHER) > > + continue; > > + > > + if (is_vlan_dev(vf_netdev)) > > + continue; > > + > > + if (netif_is_bond_master(vf_netdev)) > > + continue; > > The code above is duplicated from netvsc_netdev_event(). > Can we add a new helper function is_matching_vf() to avoid the duplication? Sure, I will do that. Thanks > > > + netvsc_prepare_bonding(vf_netdev); > > + netvsc_register_vf(vf_netdev, VF_REG_IN_PROBE); > > + __netvsc_vf_setup(net, vf_netdev); > > add a "break;' ? With MANA devices and multiport support there, the individual ports are also net_devices. Wouldn't this be needed for such scenario(where we have multiple mana port net devices) to register them all? > > > + } > > rtnl_unlock();