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 4784641EA1; Wed, 15 Mar 2023 17:02:37 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 930FF410FB; Wed, 15 Mar 2023 17:02:36 +0100 (CET) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by mails.dpdk.org (Postfix) with ESMTP id C8A0640A7A for ; Wed, 15 Mar 2023 17:02:34 +0100 (CET) Received: by mail-wr1-f47.google.com with SMTP id j2so17767414wrh.9 for ; Wed, 15 Mar 2023 09:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; t=1678896154; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=OJ42JQzXvS0y+02q6jHOOoLsIltQXBc619jyCs5ojFI=; b=HxFW9e5AEjRfr3mAV6KhVbPcQv/0WP/g1Aqh6ObwLffJpykYHQNsFl25F7dZzhMAOz bK1p6iUjXZeKN/WukapKHmb/grf3YcIyd8BvQlXgnoYmScYteKyLc9N8jP4E14qxieKm cQSYzbtyj7hpAC/S7urJw0Tfz85/yUuXnm61/OK9qrhSRroxlncy8H4ixjx7srNqlRyZ 3aHpKgK0uZYn01+4ZE5UxbA7TdFjgAJU9pUDssq8IjsQmMTaZK+ZmoaQjHJjPtYziYrz p8mVin8qTslmjlkXa9a8N+L5k4m4in3kvweC+tOY/wIP/5BuU8kruAajQuq6HylnHdId xuSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678896154; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OJ42JQzXvS0y+02q6jHOOoLsIltQXBc619jyCs5ojFI=; b=MjfYYy9YfjCGT55EOwnjoC2aH6fPNWEhmSbVknPdmBT84QHbHjig09eGj2vsnRrd2D NmCis4Tv5tUjdXZukmCvlW8hefW75MrTqgm7/Esse8UDOs8DFg0QMbCBaFNxMN6/cToV rgfuduKk76Rm0h57xQU1Ckmc2yMz1VmfgibJ5RqLpxMraZFyJE9POYilcmLdCtktW9h5 TKGkHUZrp9wFV28xdmqb2WeNjqEbIM9ksO1LK13H91lYKXLUSAT3kvhHh1KPyGk+mrSS uDviwvWWMCLw25XNR8UBFsgiYwglGotkooWWBFbQ8S/hrXCDH+1m1xWsP99jy9HTE23m bytA== X-Gm-Message-State: AO0yUKVK3vadrgH4cu2hvrAgYFSotc1IkrdI5web3yGbzfKrfSptj3tN /X/HIugyqJc/HS9sfhQdDX0LlA== X-Google-Smtp-Source: AK7set9KZHdXRCUJveTfYDaAZJZbKefxBTGkhkRoLlFKMlQXD3nNtOQsTTtsbsQbpYAFky1oO89s9w== X-Received: by 2002:adf:dbc7:0:b0:2c3:f79a:7319 with SMTP id e7-20020adfdbc7000000b002c3f79a7319mr2840000wrj.17.1678896154276; Wed, 15 Mar 2023 09:02:34 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id g16-20020a5d46d0000000b002be505ab59asm4947104wrs.97.2023.03.15.09.02.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 09:02:33 -0700 (PDT) Date: Wed, 15 Mar 2023 17:02:33 +0100 From: Olivier Matz To: David Marchand Cc: Pavel Ivashchenko , konstantin.ananyev@intel.com, mb@smartsharesystems.com, ajit.khaparde@broadcom.com, dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH] app: fix mbuf_autotest in case of defined RTE_LIBRTE_MBUF_DEBUG Message-ID: References: <20230313165605.12325-1-pivashchenko@nfware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Hello, On Wed, Mar 15, 2023 at 11:29:50AM +0100, David Marchand wrote: > Hello, > > On Mon, Mar 13, 2023 at 5:57 PM Pavel Ivashchenko > wrote: > > app: fix mbuf_autotest in case of defined RTE_LIBRTE_MBUF_DEBUG I suggest this title instead: test/mbuf: fix mbuf autotest when mbuf debug is enabled > > > > How to reproduce: > > > > 1. Define RTE_LIBRTE_MBUF_DEBUG > > 2. MALLOC_PERTURB_=178 DPDK_TEST=mbuf_autotest gdb --args obj-x86_64-linux-gnu/app/test/dpdk-test --file-prefix=mbuf_autotest > > > > PANIC in rte_mbuf_sanity_check(): > > bad pkt_len > > > > ... > > #6 0x00007ffff7d3d4cc in rte_mbuf_sanity_check (m=m@entry=0x17f8c3400, is_header=is_header@entry=1) at ../lib/mbuf/rte_mbuf.c:384 > > #7 0x0000555555653d57 in rte_pktmbuf_free (m=0x17f8c3400) at ../lib/mbuf/rte_mbuf.h:1385 > > #8 0x000055555565c7a6 in test_nb_segs_and_next_reset () at ../app/test/test_mbuf.c:2752 > > #9 test_mbuf () at ../app/test/test_mbuf.c:2967 > > ... > > > > (gdb) frame 6 > > #6 0x00007ffff7d3d4cc in rte_mbuf_sanity_check (m=m@entry=0x17f8c3400, is_header=is_header@entry=1) at ../lib/mbuf/rte_mbuf.c:384 > > 384 rte_panic("%s\n", reason); > > (gdb) p/d m->pkt_len > > $4 = 1500 > > > > Fixes: efc6f9104c80 ("mbuf: fix reset on mbuf free") > > Cc: stable@dpdk.org > > > > Signed-off-by: Pavel Ivashchenko > > LGTM, thanks. > Just a small comment. > > > > --- > > app/test/test_mbuf.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c > > index 6cbb03b0af..d471a23805 100644 > > --- a/app/test/test_mbuf.c > > +++ b/app/test/test_mbuf.c > > @@ -2744,6 +2744,7 @@ test_nb_segs_and_next_reset(void) > > > > /* split m0 chain in two, between m1 and m2 */ > > m0->nb_segs = 2; > > + m0->pkt_len -= 500; > > m0->pkt_len -= m2->data_len seems more readable and robust to me. > > Opinions? Even if the 500 is hardcoded right above, this looks indeed better. Or this seems fine too: m0->pkt_len = m0->data_len + m1->data_len; Thanks, Olivier > > > > m1->next = NULL; > > m2->nb_segs = 1; > > > > > -- > David Marchand >