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 860FEA09FE for ; Sat, 19 Dec 2020 00:33:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 59D2FCB05; Sat, 19 Dec 2020 00:33:57 +0100 (CET) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by dpdk.org (Postfix) with ESMTP id F1BEBCA9B; Sat, 19 Dec 2020 00:33:53 +0100 (CET) Received: by mail-ed1-f54.google.com with SMTP id cw27so4063149edb.5; Fri, 18 Dec 2020 15:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/oezIy8J1e+ZFnOs05SL0FaltOtJ0SvJUhQU1VCXzoA=; b=rVzfMtfaNjctwBJGRj5dVPPV5e7EDE40jjXS+zDnFaZIV0hb0LcZsqvc+Om+Gu112N mOwlW8NSQ0epD20ZAGDFwyxyE3AzAa67uG72TY7xSQIPPAc/elauCSeC9fEtb60qGHzY 4xFEFvSbS13U3oEopFFIj9nihVAJU//eNEScYQUVz0Fm0dJnn/zDGnMnNk1EH14traFz aTf17erN4f3hZE/Pl/3P9C3nEl2seq3J5Z0VELLRciE0TZw/KA3sEprvAJTqHDEHRd86 t9jQyTy4Bg65GmZgSx+3VQ+s8W+3Rv+J/N+OkubqvRsOCmUDO3KED6QFirH+oWg1WYos lilw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/oezIy8J1e+ZFnOs05SL0FaltOtJ0SvJUhQU1VCXzoA=; b=TX/4NNnFcjeT96m/kB/ORa6vCFQBvGdJcVsLXYOUHr21cQDGzY/exeO3bDAO3BlMOq 7yNoPbnLDul/Z+lBOqz23VYMboOaEYbiV5se2tfN5xgUilN4eJwKP1B/MFGB5OA7o8fA RptbUYEHVrkfRGCaiIuq0SU/GXoQEoVZq4Ne4OGMa95ZVHPC93T2UN6bxje3WZacr0nR 0s8LbTFBcxjbXGI7VQBhvnbs77xY6dIL0LQZCkRmkx1oO16HaJ1DHbRh4mhUWTx7ON6O cRsC8EbuOGJk4eg9qqT1uyaweQbPZiAsobeh4WVebDTM99+L78Rz/B8DyNPbEjkV5yEZ oXeg== X-Gm-Message-State: AOAM531dRBTMlmZWqh1uIpkNBwCfB87aVWWDv+nG/KXQsDTPcwx8I1DL HAuDFpyH+yQXezR+Wk/CtbFpXcqcTYyXSIfmf+8= X-Google-Smtp-Source: ABdhPJxmY9sDP8LVCYOI2v9op/MFKzetcNbAjkK4i47k+CDMV/BGKoitjiU1qsSb05j88cIVlmIqGvCc2KE8F7TVQyE= X-Received: by 2002:a05:6402:1a30:: with SMTP id be16mr6917509edb.124.1608334432568; Fri, 18 Dec 2020 15:33:52 -0800 (PST) MIME-Version: 1.0 References: <20201104170007.8026-1-olivier.matz@6wind.com> <20201218125238.13074-1-olivier.matz@6wind.com> <98CBD80474FA8B44BF855DF32C47DC35C614E2@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C614E2@smartserver.smartshare.dk> From: Ajit Khaparde Date: Fri, 18 Dec 2020 15:33:41 -0800 Message-ID: To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Olivier Matz , dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, konstantin.ananyev@intel.com, stable@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] mbuf: fix reset on mbuf free 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" On Fri, Dec 18, 2020 at 5:18 AM Morten Br=C3=B8rup wrote: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > > > > m->nb_seg must be reset on mbuf free whatever the value of m->next, > > because it can happen that m->nb_seg is !=3D 1. For instance in this > > case: > > > > m1 =3D rte_pktmbuf_alloc(mp); > > rte_pktmbuf_append(m1, 500); > > m2 =3D rte_pktmbuf_alloc(mp); > > rte_pktmbuf_append(m2, 500); > > rte_pktmbuf_chain(m1, m2); > > m0 =3D rte_pktmbuf_alloc(mp); > > rte_pktmbuf_append(m0, 500); > > rte_pktmbuf_chain(m0, m1); > > > > As rte_pktmbuf_chain() does not reset nb_seg in the initial m1 > > segment (this is not required), after this code the mbuf chain > > have 3 segments: > > - m0: next=3Dm1, nb_seg=3D3 > > - m1: next=3Dm2, nb_seg=3D2 > > - m2: next=3DNULL, nb_seg=3D1 > > > > Then split this chain between m1 and m2, it would result in 2 packets: > > - first packet > > - m0: next=3Dm1, nb_seg=3D3 > > - m1: next=3Dm2, nb_seg=3D2 > > I think you mean: > > - m0: next=3Dm1, nb_seg=3D2 //< nb_seg corrected > - m1: next=3DNULL, nb_seg=3D2 //< next corrected > > > - second packet > > - m2: next=3DNULL, nb_seg=3D1 > > > > Freeing the first packet will not restore nb_seg=3D1 in the second > > segment. This is an issue because it is expected that mbufs stored > > in pool have their nb_seg field set to 1. > > > > Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool") > > Cc: stable@dpdk.org > > > > Signed-off-by: Olivier Matz > > The code looks good, so: > Acked-by: Morten Br=C3=B8rup Acked-by: Ajit Khaparde