From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 9B563A00E6
for <public@inbox.dpdk.org>; Wed, 10 Jul 2019 21:13:07 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 3CBA431FC;
Wed, 10 Jul 2019 21:13:06 +0200 (CEST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dpdk.org (Postfix) with ESMTP id 371563195
for <dev@dpdk.org>; Wed, 10 Jul 2019 21:13:05 +0200 (CEST)
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
[10.5.11.22])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 79AFA7FDF8;
Wed, 10 Jul 2019 19:13:04 +0000 (UTC)
Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.208])
by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E8D81001B02;
Wed, 10 Jul 2019 19:13:03 +0000 (UTC)
From: Aaron Conole <aconole@redhat.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Ferruh Yigit <ferruh.yigit@intel.com>, Michael Santana <msantana@redhat.com>
References: <20190710183342.6459-1-aconole@redhat.com>
<20190710114230.7c171c7a@hermes.lan>
Date: Wed, 10 Jul 2019 15:13:02 -0400
In-Reply-To: <20190710114230.7c171c7a@hermes.lan> (Stephen Hemminger's message
of "Wed, 10 Jul 2019 11:42:30 -0700")
Message-ID: <f7ta7dlog8x.fsf@dhcp-25.97.bos.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(mx1.redhat.com [10.5.110.27]); Wed, 10 Jul 2019 19:13:04 +0000 (UTC)
Subject: Re: [dpdk-dev] [PATCH] rte_ether: force format string for
unformat_addr
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Wed, 10 Jul 2019 14:33:42 -0400
> Aaron Conole <aconole@redhat.com> wrote:
>
>> rte_ether_unformation_addr is very lax in what it accepts now, including
>> ethernet addresses formatted ambiguously as "x:xx:x:xx:x:xx". However,
>> previously this behavior was enforced via the my_ether_aton which would
>> fail ambiguously formatted values.
>>
>> Reported-by: Michael Santana <msantana@redhat.com>
>> Fixes: 596d31092d32 ("net: add function to convert string to ethernet address")
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> ---
>> lib/librte_net/rte_ether.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/librte_net/rte_ether.c b/lib/librte_net/rte_ether.c
>> index 8d040173c..4f252b813 100644
>> --- a/lib/librte_net/rte_ether.c
>> +++ b/lib/librte_net/rte_ether.c
>> @@ -45,7 +45,8 @@ rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea)
>> if (n == 6) {
>> /* Standard format XX:XX:XX:XX:XX:XX */
>> if (o0 > UINT8_MAX || o1 > UINT8_MAX || o2 > UINT8_MAX ||
>> - o3 > UINT8_MAX || o4 > UINT8_MAX || o5 > UINT8_MAX) {
>> + o3 > UINT8_MAX || o4 > UINT8_MAX || o5 > UINT8_MAX ||
>> + strlen(s) != RTE_ETHER_ADDR_FMT_SIZE - 1) {
>> rte_errno = ERANGE;
>> return -1;
>> }
>> @@ -58,7 +59,8 @@ rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea)
>> ea->addr_bytes[5] = o5;
>> } else if (n == 3) {
>> /* Support the format XXXX:XXXX:XXXX */
>> - if (o0 > UINT16_MAX || o1 > UINT16_MAX || o2 > UINT16_MAX) {
>> + if (o0 > UINT16_MAX || o1 > UINT16_MAX || o2 > UINT16_MAX ||
>> + strlen(s) != RTE_ETHER_ADDR_FMT_SIZE - 4) {
>> rte_errno = ERANGE;
>> return -1;
>> }
>
> NAK
> Skipping leading zero should be ok. There is no need for this patch.
Is it intended to skip the leading 0? Why not the trailing 0? I'm not
familiar with the format that is used here (example - X:XX:X:XX:X)
It isn't described in any RFC I could find (but I only did a small
search). Even in IEEE, the format is always a full octet.
> The current behavior is superset of what standard ether_aton accepts.
Okay, but it introduces a test failure for the cmdline tests and then
that test will need a few lines removed for 'unsuccessful' formats.
ether_aton is much more rigid in the formats it accepts, so the test
case is enforcing that. I guess either the current behavior of this
function changes (and since it is a new behavior of the cmdline parser,
I would think it should be changed) or the test case should be changed
to adopt it.