From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by dpdk.org (Postfix) with ESMTP id 46DA62B9F for ; Fri, 1 Apr 2016 16:58:21 +0200 (CEST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AF1013F4074; Fri, 1 Apr 2016 14:58:20 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8F6BE3F406C; Fri, 1 Apr 2016 14:58:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459522700; bh=hiZawbtNQxdXciNTwWB/BsJDcF+3vAGzVY9rAX/hX2E=; l=2627; h=From:To:Date:From; b=LpVzMavarZSQAqk/yJ5FP8/WUOQVLdn07H596jECGnu0ViGerj15GKi2qk3BXPVSM vxRuHVlO6bPEg7TopOu/Kk+QfZyYDKXDn45SUL/vHMl2+Dp2EmOyjdM6AsbMz4o4Gl 3V1p0WQ7u9jQu16XHoGSaRci+TOvjQkeFZU3syc8= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 738A21FCA6; Fri, 1 Apr 2016 14:58:20 +0000 (GMT) Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 1 Apr 2016 09:58:19 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1130.005; Fri, 1 Apr 2016 07:58:19 -0700 From: "Sanford, Robert" To: "Dumitrescu, Cristian" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 2/4] port: fix ring writer buffer overflow Thread-Index: AQHRjCbtAW0KT3ujKUyEKOLYEzQDiA== Date: Fri, 1 Apr 2016 14:58:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.132.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/4] port: fix ring writer buffer overflow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:58:21 -0000 > > >> -----Original Message----- >> From: Robert Sanford [mailto:rsanford2@gmail.com] >> Sent: Monday, March 28, 2016 9:52 PM >> To: dev@dpdk.org; Dumitrescu, Cristian >> Subject: [PATCH 2/4] port: fix ring writer buffer overflow >>=20 >> Ring writer tx_bulk functions may write past the end of tx_buf[]. >> Solution is to double the size of tx_buf[]. >>=20 >> Signed-off-by: Robert Sanford >> --- >> lib/librte_port/rte_port_ring.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >>=20 >> diff --git a/lib/librte_port/rte_port_ring.c >>b/lib/librte_port/rte_port_ring.c >> index b847fea..765ecc5 100644 >> --- a/lib/librte_port/rte_port_ring.c >> +++ b/lib/librte_port/rte_port_ring.c >> @@ -179,7 +179,7 @@ rte_port_ring_reader_stats_read(void *port, >> struct rte_port_ring_writer { >> struct rte_port_out_stats stats; >>=20 >> - struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX]; >> + struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX]; >> struct rte_ring *ring; >> uint32_t tx_burst_sz; >> uint32_t tx_buf_count; >> @@ -447,7 +447,7 @@ rte_port_ring_writer_stats_read(void *port, >> struct rte_port_ring_writer_nodrop { >> struct rte_port_out_stats stats; >>=20 >> - struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX]; >> + struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX]; >> struct rte_ring *ring; >> uint32_t tx_burst_sz; >> uint32_t tx_buf_count; >> -- >> 1.7.1 > >Hi Robert, > >How is the buffer overflow taking place? > >After looking long and hard, I spotted that buffer overflow can >potentially take place when the following conditions are met: >1. The input packet burst does not meet the conditions of (a) being >contiguous (first n bits set in pkts_mask, all the other bits cleared) >and (b) containing a full burst, i.e. at least tx_burst_sz packets (n >=3D >tx_burst_size). This is the slow(er) code path taken when local variable >expr !=3D 0. >2. There are some packets already in the buffer. >3. The number of packets in the incoming burst (i.e. popcount(pkts_mask)) >plus the number of packets already in the buffer exceeds the buffer size >(RTE_PORT_IN_BURST_SIZE_MAX, i.e. 64). > >Is this the buffer overflow scenario that you detected? > >Thanks, >Cristian > Hi Cristian, Thanks for looking at the patches. Yes, the buffer overflow occurs in the scenario you described. The additional testing steps in patch 1/4 expose the overflow. The first time that I run the table_autotest, it fails. The second time, the process crashes. -- Robert