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 BF2D242814 for ; Thu, 23 Mar 2023 00:43:04 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 97D3A4021E; Thu, 23 Mar 2023 00:43:04 +0100 (CET) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by mails.dpdk.org (Postfix) with ESMTP id 7DE0540156 for ; Thu, 23 Mar 2023 00:43:03 +0100 (CET) Received: by mail-pl1-f171.google.com with SMTP id k2so20742047pll.8 for ; Wed, 22 Mar 2023 16:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1679528582; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=bm4VF47Nw5dtyFCfpckMm4MstCpVNy5LW+VRDLvBCbE=; b=NdrdhAlrrsSPyau3BLUObpA6OPzh99d4hi/UPsnFx01326qH+DsFquMr3sz+IMre+l p1O8XNs/O1KNJMqqZ11SywD5zJt6c38HpCCi4Q4O9kphHzGoFKKtoqCZxvmLy7GUjrhL 9a/AJny2DTyBc2O3Pofw6SMB+/WKLr49tru1/sj74Oz8nixOVuPCtzajlYBtC4KTbSPZ cZSZPIp6n88OEi/HNCQRptncGIxZ71nTUTotQpc/EtR342GZCcM0oC/coc43W/YwyROG upsiplWbIxoDcusXf8TNi9vK4GkpV58MQuVkz0yG3BPORhgtsCD1ef7PLyXhmhv9bJ2S zqIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679528582; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bm4VF47Nw5dtyFCfpckMm4MstCpVNy5LW+VRDLvBCbE=; b=eL8/TAJ14nqecD+kAE9T35+zIr/+eu/bppjuAjFN2nVSobnTdBm0fVKz5929xKdJsB 6pMlpc3mTO2uoha6oitdgv1naZ6tH3k7tnorGS99r6BRFFvPT8MWfqpaob1Vfmnq/jIZ 8g31jzJLWKL0n4w44LQqBvaLUAVLZT9GMA5XYyeVTds0Hv1rOOWgt+1oVsohxPAzcOV8 wz4sZq0kh72wJylsTdXu3FkHS3CIJWd/iTZUTQIvM8kPzT7zKv3VD5ET0ly9a6jLGt7N jYGbRbn5w/TYNKKGA6ZXX2Lr4BLsRAeq0e1iYV4n8ChAf6407cNmO9xmDZtzR8o3HvDO yM6w== X-Gm-Message-State: AO0yUKXCiZ+njB86qgJJG+4IiKwd9bU/HZVqdLCz9DXmdMoXOfKtJgsx ulqtG5Hse9BAY7JTyqnIiWJhJRLD55+uQsnoaOSK8w== X-Google-Smtp-Source: AK7set+FfnUpEErLDt8zOWlXQFZOl+QOjvKtdw1jLIxjXJp7j+rVK1nflqcC2lQKFmfpB72jAk1B0g== X-Received: by 2002:a17:90b:350e:b0:23f:2c65:fab7 with SMTP id ls14-20020a17090b350e00b0023f2c65fab7mr5362168pjb.42.1679528582328; Wed, 22 Mar 2023 16:43:02 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id ha2-20020a17090af3c200b00233864f21a7sm42244pjb.51.2023.03.22.16.43.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 16:43:02 -0700 (PDT) Date: Wed, 22 Mar 2023 16:43:00 -0700 From: Stephen Hemminger To: David Christensen Cc: dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH] net/tap: resolve stringop-overflow with gcc 12 on ppc64le Message-ID: <20230322164300.2402d9f1@hermes.local> In-Reply-To: <20230322212439.524725-1-drc@linux.vnet.ibm.com> References: <20230322212439.524725-1-drc@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Wed, 22 Mar 2023 17:24:39 -0400 David Christensen wrote: > Building DPDK with gcc 12 on a ppc64le system generates a > stringop-overflow warning. Replace the local MAC address > validation function parse_user_mac() with a call to > rte_ether_unformat_addr() instead. > > Bugzilla ID: 1197 > Cc: stable@dpdk.org > > Signed-off-by: David Christensen > --- > drivers/net/tap/rte_eth_tap.c | 25 +------------------------ > 1 file changed, 1 insertion(+), 24 deletions(-) > > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c > index 089ac202fa..1f83f49c0e 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -2267,29 +2267,6 @@ set_remote_iface(const char *key __rte_unused, > return 0; > } > > -static int parse_user_mac(struct rte_ether_addr *user_mac, > - const char *value) > -{ > - unsigned int index = 0; > - char mac_temp[strlen(ETH_TAP_USR_MAC_FMT) + 1], *mac_byte = NULL; > - > - if (user_mac == NULL || value == NULL) > - return 0; > - > - strlcpy(mac_temp, value, sizeof(mac_temp)); > - mac_byte = strtok(mac_temp, ":"); > - > - while ((mac_byte != NULL) && > - (strlen(mac_byte) <= 2) && > - (strlen(mac_byte) == strspn(mac_byte, > - ETH_TAP_CMP_MAC_FMT))) { > - user_mac->addr_bytes[index++] = strtoul(mac_byte, NULL, 16); > - mac_byte = strtok(NULL, ":"); > - } > - > - return index; > -} > - > static int > set_mac_type(const char *key __rte_unused, > const char *value, > @@ -2311,7 +2288,7 @@ set_mac_type(const char *key __rte_unused, > goto success; > } > > - if (parse_user_mac(user_mac, value) != 6) > + if (rte_ether_unformat_addr(value, user_mac) < 0) > goto error; > success: > TAP_LOG(DEBUG, "TAP user MAC param (%s)", value); There might still be case where user_mac == NULL since it comes from extra_args. Also, this code has this suspicious code: if (!strncasecmp(ETH_TAP_MAC_FIXED, value, strlen(ETH_TAP_MAC_FIXED))) { static int iface_idx; /* fixed mac = 00:64:74:61:70: */ memcpy((char *)user_mac->addr_bytes, "\0dtap", RTE_ETHER_ADDR_LEN); user_mac->addr_bytes[RTE_ETHER_ADDR_LEN - 1] = iface_idx++ + '0'; goto success; } The OUI for that MAC address is not registered but it might be someday. Choosing magic constants in IANA assigned space is not best practice. Unless some vendor wants to spend lots of time registering these. Better to use locally assigned value. See RFC7042 for more details.