From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 1A052A84C for ; Tue, 16 Jan 2018 15:19:31 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 06:19:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,368,1511856000"; d="scan'208";a="26875769" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga002.jf.intel.com with ESMTP; 16 Jan 2018 06:19:30 -0800 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 16 Jan 2018 06:19:30 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.21]) by FMSMSX152.amr.corp.intel.com ([169.254.6.129]) with mapi id 14.03.0319.002; Tue, 16 Jan 2018 06:19:30 -0800 From: "Wiles, Keith" To: Olivier Matz CC: "dev@dpdk.org" , "stephen@networkplumber.org" , "jerin.jacob@caviumnetworks.com" Thread-Topic: [dpdk-dev] [PATCH v2] mbuf:using sanity checks do not panic on null mbuf Thread-Index: AQHTjtL2+oU+VCW0a0S09Q6Gk7c4CaN3En8A Date: Tue, 16 Jan 2018 14:19:29 +0000 Message-ID: <430903DF-0219-4AB6-993C-8DE5915D7CCA@intel.com> References: <20180108153423.57648-1-keith.wiles@intel.com> <20180109142928.81687-1-keith.wiles@intel.com> <20180116140429.pyab272uebox2gmn@platinum> In-Reply-To: <20180116140429.pyab272uebox2gmn@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.81.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <8C10F08C17E2AE47A052F3E943AB564E@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] mbuf:using sanity checks do not panic on null mbuf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 14:19:32 -0000 > On Jan 16, 2018, at 8:04 AM, Olivier Matz wrote: >=20 > On Tue, Jan 09, 2018 at 08:29:28AM -0600, Keith Wiles wrote: >> The rte_pktmbuf_free() allows for NULL mbuf pointer, but >> when sanity check is enabled it will panic with null pointer. >>=20 >> Signed-off-by: Keith Wiles >> --- >> lib/librte_mbuf/rte_mbuf.c | 10 ++++++++-- >> test/test/test_mbuf.c | 4 +--- >> 2 files changed, 9 insertions(+), 5 deletions(-) >>=20 >> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c >> index 7543662f7..621679c92 100644 >> --- a/lib/librte_mbuf/rte_mbuf.c >> +++ b/lib/librte_mbuf/rte_mbuf.c >> @@ -205,8 +205,9 @@ rte_mbuf_sanity_check(const struct rte_mbuf *m, int = is_header) >> const struct rte_mbuf *m_seg; >> unsigned int nb_segs; >>=20 >> - if (m =3D=3D NULL) >> - rte_panic("mbuf is NULL\n"); >> + /* Calling with NULL is valid in the API */ >> + if (!m) >> + return; >>=20 >> /* generic checks */ >> if (m->pool =3D=3D NULL) >> @@ -243,6 +244,11 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m,= unsigned dump_len) >>=20 >> __rte_mbuf_sanity_check(m, 1); >>=20 >> + if (!m) { >> + fprintf(stderr, "MBUF pointer is NULL\n"); >> + return; >> + } >> + >> fprintf(f, "dump mbuf at %p, iova=3D%"PRIx64", buf_len=3D%u\n", >> m, (uint64_t)m->buf_iova, (unsigned)m->buf_len); >> fprintf(f, " pkt_len=3D%"PRIu32", ol_flags=3D%"PRIx64", nb_segs=3D%u, = " >> diff --git a/test/test/test_mbuf.c b/test/test/test_mbuf.c >> index 9e82a20be..146eaf0e5 100644 >> --- a/test/test/test_mbuf.c >> +++ b/test/test/test_mbuf.c >> @@ -864,10 +864,8 @@ test_failing_mbuf_sanity_check(struct rte_mempool *= pktmbuf_pool) >>=20 >> printf("Now checking for error conditions\n"); >>=20 >> - if (verify_mbuf_check_panics(NULL)) { >> - printf("Error with NULL mbuf test\n"); >> + if (verify_mbuf_check_panics(NULL) !=3D -1) >> return -1; >> - } >>=20 >> badbuf =3D *buf; >> badbuf.pool =3D NULL; >> --=20 >> 2.14.1 >>=20 >=20 > The problem is a panic when rte_pktmbuf_free(NULL) when mbuf debug is ena= bled, > right? >=20 > A NULL mbuf is only valid in case of a free because it is convenient, but= for > most (all ?) other mbuf functions, the mbuf must not be NULL. >=20 > What about this patch instead: >=20 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -1413,13 +1413,14 @@ rte_pktmbuf_free_seg(struct rte_mbuf *m) > * segment is added back into its original mempool. > * > * @param m > - * The packet mbuf to be freed. > + * The packet mbuf to be freed. If NULL, the function does nothing. > */ > static inline void rte_pktmbuf_free(struct rte_mbuf *m) > { > struct rte_mbuf *m_next; >=20 > - __rte_mbuf_sanity_check(m, 1); > + if (m !=3D NULL) > + __rte_mbuf_sanity_check(m, 1); >=20 > while (m !=3D NULL) { > m_next =3D m->next; Looks good to me I would ack that one. :-) >=20 Regards, Keith