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 65BA542814; Thu, 23 Mar 2023 00:43:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B99864161A; Thu, 23 Mar 2023 00:43:04 +0100 (CET) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 7F88C4021E for ; Thu, 23 Mar 2023 00:43:03 +0100 (CET) Received: by mail-pj1-f50.google.com with SMTP id lr16-20020a17090b4b9000b0023f187954acso265809pjb.2 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=PvLd1XF59P7ilKlw5RKnEscD4lppUBWX2j7PhXBgJf1khc8CvUQJVyKHaA7YILbPR9 M55NZPzbRfvw6HJGkpV7EEyiWSpUFC9nZPVpg1SPwepkbZzowxXVBzC1ljK4dxcesS9s SuRCeh5DAvyjwPuKPNEO83kRS2eRQLFAErV7TYOTupz2ysZJ1/CmR0JYXn2798VSsc99 Wsl5N7jijvmXCcva+HgncnHcy0LjEQo/B96LPii2VrESld8zsvRHWGezY8atHeP71vfg teqEDD6uRlEh1P1OZ3fVNK8nyCMqifbz+c8RDwWkA7YwujkcbotLyj0V8yWfy1mXgXFF t47A== X-Gm-Message-State: AO0yUKUn9/0Rrr+6wddfLRyh2SXQrofwkSh0CqVUtnFva56r1+q4e5Yo aUvmmhHfVXK6SwOkuYvGG38WhQ== 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: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-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.