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=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT 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 F2191ECDE30 for ; Wed, 17 Oct 2018 13:17:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B3EF21523 for ; Wed, 17 Oct 2018 13:17:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="QhCD6QO1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B3EF21523 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727245AbeJQVNA (ORCPT ); Wed, 17 Oct 2018 17:13:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:38052 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727047AbeJQVNA (ORCPT ); Wed, 17 Oct 2018 17:13:00 -0400 Received: from localhost (ip-213-127-77-176.ip.prioritytelecom.net [213.127.77.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C98F121523; Wed, 17 Oct 2018 13:17:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539782240; bh=LA4+4eF/oi7GUeZ5c37vmor7VcBhYifztk98dm6Jizg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QhCD6QO1vBYAGzkBtXxr83Ua2m+cfay62y6Nm0tt85WvOHdv55IXEanRv3bBlzmGT /NllDGgIWuEJKKp3TaseVQrvALTaKIQ/xi5vRJFg22ZAQPCz5U42FRcG4a+Jz9E1RF +n2VyimYJT+9BqTZswbtR5boFHxUlMEiUFDgcAe8= Date: Wed, 17 Oct 2018 15:17:17 +0200 From: Greg Kroah-Hartman To: Haiyang Zhang Cc: "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Stephen Hemminger , "David S. Miller" , Sasha Levin Subject: Re: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number Message-ID: <20181017131717.GA10130@kroah.com> References: <20181016170515.447235311@linuxfoundation.org> <20181016170522.303317746@linuxfoundation.org> <20181017074629.GD25537@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 17, 2018 at 01:02:17PM +0000, Haiyang Zhang wrote: > > > > -----Original Message----- > > From: Greg Kroah-Hartman > > Sent: Wednesday, October 17, 2018 3:46 AM > > To: Haiyang Zhang > > Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org; Stephen Hemminger > > ; David S. Miller ; Sasha > > Levin > > Subject: Re: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number > > > > On Tue, Oct 16, 2018 at 07:13:12PM +0000, Haiyang Zhang wrote: > > > > > > > > > > -----Original Message----- > > > > From: linux-kernel-owner@vger.kernel.org > > > owner@vger.kernel.org> On Behalf Of Greg Kroah-Hartman > > > > Sent: Tuesday, October 16, 2018 1:06 PM > > > > To: linux-kernel@vger.kernel.org > > > > Cc: Greg Kroah-Hartman ; > > > > stable@vger.kernel.org; Stephen Hemminger ; > > > > David S. Miller ; Sasha Levin > > > > > > > > Subject: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial > > > > number > > > > > > > > 4.18-stable review patch. If anyone has any objections, please let me know. > > > > > > > > ------------------ > > > > > > > > From: Stephen Hemminger > > > > > > > > [ Upstream commit 00d7ddba1143623b31bc2c15d18216e2da031b14 ] > > > > > > > > Matching network device based on MAC address is problematic since a > > > > non VF network device can be creted with a duplicate MAC address > > > > causing confusion and problems. The VMBus API does provide a serial > > > > number that is a better matching method. > > > > > > > > Signed-off-by: Stephen Hemminger > > > > Signed-off-by: David S. Miller > > > > Signed-off-by: Sasha Levin > > > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > > > drivers/net/hyperv/netvsc.c | 3 ++ > > > > drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++++++++------------ > > ----- > > > > - > > > > 2 files changed, 36 insertions(+), 25 deletions(-) > > > > > > > > --- a/drivers/net/hyperv/netvsc.c > > > > +++ b/drivers/net/hyperv/netvsc.c > > > > @@ -1203,6 +1203,9 @@ static void netvsc_send_vf(struct net_de > > > > > > > > net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated; > > > > net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial; > > > > + netdev_info(ndev, "VF slot %u %s\n", > > > > + net_device_ctx->vf_serial, > > > > + net_device_ctx->vf_alloc ? "added" : "removed"); > > > > } > > > > > > > > static void netvsc_receive_inband(struct net_device *ndev, > > > > --- a/drivers/net/hyperv/netvsc_drv.c > > > > +++ b/drivers/net/hyperv/netvsc_drv.c > > > > @@ -1794,20 +1794,6 @@ out_unlock: > > > > rtnl_unlock(); > > > > } > > > > > > > > -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ > > > > - struct net_device_context *ndev_ctx; > > > > - > > > > - list_for_each_entry(ndev_ctx, &netvsc_dev_list, list) { > > > > - struct net_device *dev = hv_get_drvdata(ndev_ctx- > > > > >device_ctx); > > > > - > > > > - if (ether_addr_equal(mac, dev->perm_addr)) > > > > - return dev; > > > > - } > > > > - > > > > - return NULL; > > > > -} > > > > - > > > > static struct net_device *get_netvsc_byref(struct net_device *vf_netdev) { > > > > struct net_device_context *net_device_ctx; @@ -1936,26 +1922,48 > > @@ > > > > static void netvsc_vf_setup(struct work_ > > > > rtnl_unlock(); > > > > } > > > > > > > > +/* Find netvsc by VMBus serial number. > > > > + * The PCI hyperv controller records the serial number as the slot. > > > > + */ > > > > +static struct net_device *get_netvsc_byslot(const struct net_device > > > > +*vf_netdev) { > > > > + struct device *parent = vf_netdev->dev.parent; > > > > + struct net_device_context *ndev_ctx; > > > > + struct pci_dev *pdev; > > > > + > > > > + if (!parent || !dev_is_pci(parent)) > > > > + return NULL; /* not a PCI device */ > > > > + > > > > + pdev = to_pci_dev(parent); > > > > + if (!pdev->slot) { > > > > + netdev_notice(vf_netdev, "no PCI slot information\n"); > > > > + return NULL; > > > > + } > > > > + > > > > + list_for_each_entry(ndev_ctx, &netvsc_dev_list, list) { > > > > + if (!ndev_ctx->vf_alloc) > > > > + continue; > > > > + > > > > + if (ndev_ctx->vf_serial == pdev->slot->number) > > > > + return hv_get_drvdata(ndev_ctx->device_ctx); > > > > > > Greg, > > > > > > I had a fix to this patch. If not already, Could you include my following fix > > together? > > > hv_netvsc: fix vf serial matching with pci slot info > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k > > > ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fdavem%2Fnet- > > next.git%2F > > > > > commit%2F%3Fid%3D005479556197f80139771960dda0dfdcd2d2aad5&da > > ta=02% > > > > > 7C01%7Chaiyangz%40microsoft.com%7C6ce194a47449435fe82a08d63404a94e > > %7C7 > > > > > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753591959679786& > > ;sdata > > > > > =ReWYMZW%2FYtoFSbFSxny9VGw6V8v9J4sGanfJjbVd34A%3D&reserved= > > 0 > > > > I can not take a patch that is not "upstream" yet, sorry. > > > > Also, this really feels like a "new feature" to me. Can someone explain what > > bug this is fixing? > > Patch #A: hv_netvsc: pair VF based on serial number > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=00d7ddba1143623b31bc2c15d18216e2da031b14 > > Patch #B: hv_netvsc: fix vf serial matching with pci slot info > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=005479556197f80139771960dda0dfdcd2d2aad5 > > The patch #A is a feature that use VF serial number for matching. But #A has a bug causing mismatch. > > Patch #B, upstream now (see the link to Linux-next), is a fix to #A. linux-next is not "upstream", it needs to be in Linus's tree, you know this :( > So, if #A is ported to 4.18, we need to port #B together. Otherwise, not porting both the #A and #B is also fine. You didn't answer my original question here, what bug is this fixing? I'll go drop this from the tree for now anyway... thanks, greg k-h