From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DCD61A0518 for ; Fri, 24 Jul 2020 14:07:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D45FF1C196; Fri, 24 Jul 2020 14:07:48 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id BEBE81C196 for ; Fri, 24 Jul 2020 14:07:47 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id 88so8094700wrh.3 for ; Fri, 24 Jul 2020 05:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bhUppajOMHvAQnr679J8hEFxvYSTe9s6/PndiWT1NUo=; b=M2QLqxCYPzkTyDHQfi1/SKQQZeXrw2jvrHpsCwlyRZfzZvrVPWvrIFzuoESAYJXLrJ QRn6RPNr7pyA7apA/YZ+xxIPgiVRk8+O2mY5Xt49em+XgvgwqHKteXQPog+maefVllZp t71Pusnqz0bT/E1qmI0LljEZpLGAhPuXBok9lDCVi1/cq/AK/qGmyZSn8OWF1Eh144IG egbWTAu8wOJLRPugP2YmEouFkx+XEr3NUsoCr+yT8qvDKVPic6rVplXsiNCLGVTMwnXH KMZBwxCdLw2tSk3xRNk6iiheBXi0ZAMV2x+ZLjGhjq15RnSyq1njBFHWhHjvUdq+t25G dtXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bhUppajOMHvAQnr679J8hEFxvYSTe9s6/PndiWT1NUo=; b=nDwNq7jXNonOslYNzsXGomgi9fgeNet8pxwGGuBHBwIE22CCk9tF2o2K2bbgLotaRj WTwvcMz08u6g+UTnAolO5+aS7sGUpEwESXgz0TQdY6UkS9k4JSAKrbLqHOapRy1nVlD9 LsKyU/lvkNWsM9bJuoChltURfOS6fHUXunEAVJDMqG4+TD1tuQXrV418j3Cx24QudvSK 5pUcITpHG+ToTpVDGM8VeXHwCM3o47X2rWoc/xd4FzoVItifjpMMvQ2f6DTG5GZ5z1ha v1V094I4nzeQJ5B+FemQ0KS4BRxwmjBuiH5ZSJp/eRHZSuhainSfwnXX6OkeYQNOiiw/ VyCA== X-Gm-Message-State: AOAM530MV3K9QBlcW4V8ge2seYpFiCuaAHX7lNvQ+5u3RxmBg4SkUF3B kgIXxj2DxY3Lq+8gG5IeuE8= X-Google-Smtp-Source: ABdhPJwowuksRdyF423SGJZehIq3xgZo9kbpiXVDi+46AyLVkMyiKo5GZm8FLfvElZt9/bHLveWDPg== X-Received: by 2002:a5d:4710:: with SMTP id y16mr8634667wrq.189.1595592467510; Fri, 24 Jul 2020 05:07:47 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id p25sm6587804wma.39.2020.07.24.05.07.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2020 05:07:46 -0700 (PDT) From: luca.boccassi@gmail.com To: Ferruh Yigit Cc: Qi Zhang , dpdk stable Date: Fri, 24 Jul 2020 12:59:04 +0100 Message-Id: <20200724120030.1863487-106-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200724120030.1863487-1-luca.boccassi@gmail.com> References: <20200724120030.1863487-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'net/iavf: fix uninitialized variable' has been queued to stable release 19.11.4 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 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 Sender: "stable" Hi, FYI, your patch has been queued to stable release 19.11.4 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 07/26/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Thanks. Luca Boccassi --- >From 8edaa43add38c967cd9b50b8e1cc16329596f445 Mon Sep 17 00:00:00 2001 From: Ferruh Yigit Date: Tue, 23 Jun 2020 14:45:31 +0100 Subject: [PATCH] net/iavf: fix uninitialized variable MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit [ upstream commit ca5e39f8535300b247d14865cd8c6b9b4acba38a ] This is observed with experimental gcc 11, although the older gcc versions don't complain about it, issue seems a valid one. gcc version 11.0.0 20200621 (experimental) (GCC) Build error .../drivers/net/iavf/iavf_ethdev.c: In function ‘iavf_dev_link_update’: .../drivers/net/iavf/iavf_ethdev.c:641:6: error: ‘new_link’ is used uninitialized [-Werror=uninitialized] 641 | if (rte_atomic64_cmpset((uint64_t *)&dev->data->dev_link, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 642 | *(uint64_t *)&dev->data->dev_link, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 643 | *(uint64_t *)&new_link) == 0) | ~~~~~~~~~~~~~~~~~~~~~~~ .../drivers/net/iavf/iavf_ethdev.c:596:22: note: ‘new_link’ declared here 596 | struct rte_eth_link new_link; | ^~~~~~~~ cc1: all warnings being treated as error All fields of the 'new_link' struct is already set in function, so the 'uninitialized' warning is hard to get. This is because the combination of aligning and bitfield usage of the struct The definition of the struct is: struct rte_eth_link { uint32_t link_speed; /**< ETH_SPEED_NUM_ */ uint16_t link_duplex : 1; /**< ETH_LINK_[HALF/FULL]_DUPLEX */ uint16_t link_autoneg : 1; /**< ETH_LINK_[AUTONEG/FIXED] */ uint16_t link_status : 1; /**< ETH_LINK_[DOWN/UP] */ } __rte_aligned(8); /**< aligned for atomic64 read/write */ Overall the size of the 'struct rte_eth_link' is 64 bits, but function only sets the 35 bits of it, because only 3 bits of 16 bits variable are used. When the struct cast to 'uint64_t' because of the 'rte_atomic64_cmpset' the upper 29 bits are used without initialization. To fix the uninitialized usage, memset the variable 'new_link' before using it. Fixes: 48de41ca11f0 ("net/avf: enable link status update") Signed-off-by: Ferruh Yigit Acked-by: Qi Zhang --- drivers/net/iavf/iavf_ethdev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c index 266200dbe..3f41eefff 100644 --- a/drivers/net/iavf/iavf_ethdev.c +++ b/drivers/net/iavf/iavf_ethdev.c @@ -593,6 +593,8 @@ iavf_dev_link_update(struct rte_eth_dev *dev, struct rte_eth_link new_link; struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private); + memset(&new_link, 0, sizeof(new_link)); + /* Only read status info stored in VF, and the info is updated * when receive LINK_CHANGE evnet from PF by Virtchnnl. */ -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-07-24 12:53:52.630171832 +0100 +++ 0106-net-iavf-fix-uninitialized-variable.patch 2020-07-24 12:53:48.359007801 +0100 @@ -1,4 +1,4 @@ -From ca5e39f8535300b247d14865cd8c6b9b4acba38a Mon Sep 17 00:00:00 2001 +From 8edaa43add38c967cd9b50b8e1cc16329596f445 Mon Sep 17 00:00:00 2001 From: Ferruh Yigit Date: Tue, 23 Jun 2020 14:45:31 +0100 Subject: [PATCH] net/iavf: fix uninitialized variable @@ -6,6 +6,8 @@ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit +[ upstream commit ca5e39f8535300b247d14865cd8c6b9b4acba38a ] + This is observed with experimental gcc 11, although the older gcc versions don't complain about it, issue seems a valid one. gcc version 11.0.0 20200621 (experimental) (GCC) @@ -48,7 +50,6 @@ using it. Fixes: 48de41ca11f0 ("net/avf: enable link status update") -Cc: stable@dpdk.org Signed-off-by: Ferruh Yigit Acked-by: Qi Zhang @@ -57,10 +58,10 @@ 1 file changed, 2 insertions(+) diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c -index d69e5284e..b0dd49a8d 100644 +index 266200dbe..3f41eefff 100644 --- a/drivers/net/iavf/iavf_ethdev.c +++ b/drivers/net/iavf/iavf_ethdev.c -@@ -582,6 +582,8 @@ iavf_dev_link_update(struct rte_eth_dev *dev, +@@ -593,6 +593,8 @@ iavf_dev_link_update(struct rte_eth_dev *dev, struct rte_eth_link new_link; struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);