From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) by dpdk.org (Postfix) with ESMTP id 6A661B394 for ; Sat, 6 Sep 2014 02:10:06 +0200 (CEST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 897AEB945A47D for ; Sat, 6 Sep 2014 00:14:50 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s860Erc6017568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Sep 2014 20:14:53 -0400 Received: from mvlnxjsacha.eng.timetra.com (135.5.27.17) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 5 Sep 2014 20:14:53 -0400 Message-ID: <540A51FA.3070905@alcatel-lucent.com> Date: Fri, 5 Sep 2014 17:14:50 -0700 From: Jan Sacha User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Thunderbird/17.0.10 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.17] Subject: [dpdk-dev] rte_lpm_add in librte_lpm 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: Sat, 06 Sep 2014 00:10:06 -0000 Hi, I've been playing with DPDK and I got some crashes in the LPM module. As far as I know, this problem has not been reported yet. These crashes happened in DPDK 1.7.0 and 1.6.0r2 (I didn't check other versions) when I added new LPM routes. In the lib/librte_lpm/rte_lpm.c file, line 399 (add_depth_small function), there is the following condition: if (!lpm->tbl24[i].valid || (lpm->tbl24[i].ext_entry == 0 && lpm->tbl24[i].depth <= depth)) If the new route has a lower depth than an existing non-extended entry, this condition is not met. We then skip to line 418, where we assume the entry is extended and use an uninitialized index. Is this a bug? Thanks, Jan