From patchwork Fri Apr 13 18:42:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrien Mazarguil X-Patchwork-Id: 38090 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4D9851C6C4; Fri, 13 Apr 2018 20:43:14 +0200 (CEST) Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id 4456F1BC5E for ; Fri, 13 Apr 2018 20:43:13 +0200 (CEST) Received: by mail-wr0-f193.google.com with SMTP id d19so10488292wre.1 for ; Fri, 13 Apr 2018 11:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qoOri4QjTLqRKR6MHuD+kr9f94+LIUhMTj1mHslMZ3g=; b=1qoUdq+3P/bcGuMalaqVayjLkFPrCksgx6AMCrUqjNx2DzCzhHvTFw9JijgjGNe1el hvwAOKI++kWAzGok5Z7Y5KOuPSfPILifiAi9IfMKdHNgEqOW2kQUMNcOiyE3QtbbJRjb qq/Q6yuq4ktNiw75mTzxMDFhZW1Hpi7qBBaB83pwmeiw9byGTK/PzK0UfjSpONOTXJUD QAKG0AnSkniljQQvMckDMFr7woIDQ9HNulLgz9KqE03nJ0UsVntPXZyyCF/m/IzyXw3D pJcIIEc639aAkYeIUWVXLZ91nh2TQIUxHL3RY9lNsqs8aDYFnCVQnSg2nz7n4RKoAcf6 YY0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qoOri4QjTLqRKR6MHuD+kr9f94+LIUhMTj1mHslMZ3g=; b=Ut4bVx3KFBqFjyaNcG8lkDZCGRkQQTOiAgLCiM2xnk37/5VwQujQcJKbW+1eKm26z8 4f5oFk5ehXT5R0jhl8MG8LgOd3IlyFbboqgbDlvjOKyycbB6mhvlb9PxaDNL4tb5M9zu 4SD/5zbYhTxIEgBPVk6mEBbvkdl6yBltuCm9U07RevwpQczdiMvS57ZL1JVpeelgj3lP SZtrdJstTOTXwbd9Mnd22zWqzesnhGo5Vn2Ym//TG9hUOGlSybFR4Z7MhyzhStJcd7rQ RK+pxUHqsr8sQi//Jmjc8bxGvrnHtgSqDGEWdd7lhtNZGbBVwPb2qRelkZLz26BRSSaz mvCw== X-Gm-Message-State: ALQs6tDIgPorDc2HU97gsV+vTcCML+LpvuvEzjafEqIMgt1h1efQIvSF 1AS6OHRQ4KskwvPtMmzkfdxA0g== X-Google-Smtp-Source: AIpwx4/Mr5Om7xpzPEzGG6/R093XmR/ZrMumy5vRK3FcTArP3FhBSO+3weW13P8dZx8hxj+3zxkNPw== X-Received: by 10.28.230.11 with SMTP id d11mr4203226wmh.129.1523644993000; Fri, 13 Apr 2018 11:43:13 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id y191sm3514547wme.14.2018.04.13.11.43.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 11:43:12 -0700 (PDT) Date: Fri, 13 Apr 2018 20:42:58 +0200 From: Adrien Mazarguil To: Anatoly Burakov Cc: dev@dpdk.org Message-ID: <20180413183950.17625-1-adrien.mazarguil@6wind.com> References: <20180413155417.29643-1-adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180413155417.29643-1-adrien.mazarguil@6wind.com> X-Mailer: git-send-email 2.11.0 Subject: [dpdk-dev] [PATCH v3 1/2] eal: fix undefined behavior in fbarray 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" According to GCC documentation [1], the __builtin_clz() family of functions yield undefined behavior when fed a zero value. There is one instance in the fbarray code where this can occur. Clang (at least version 3.8.0-2ubuntu4) seems much more sensitive to this than GCC and yields random results when compiling optimized code, as shown below: #include int main(void) { volatile unsigned long long moo; int x; moo = 0; x = __builtin_clzll(moo); printf("%d\n", x); return 0; } $ gcc -O3 -o test test.c && ./test 63 $ clang -O3 -o test test.c && ./test 1742715559 $ clang -O0 -o test test.c && ./test 63 Even 63 can be considered an unexpected result given the number of leading zeroes should be the full width of the underlying type, i.e. 64. In practice it causes find_next_n() to sometimes return negative values interpreted as errors by caller functions, which prevents DPDK applications from starting due to inability to find free memory segments: # testpmd [...] EAL: Detected 32 lcore(s) EAL: Detected 2 NUMA nodes EAL: No free hugepages reported in hugepages-1048576kB EAL: Multi-process socket /var/run/.rte_unix EAL: eal_memalloc_alloc_seg_bulk(): couldn't find suitable memseg_list EAL: FATAL: Cannot init memory EAL: Cannot init memory PANIC in main(): Cannot init EAL 4: [./build/app/testpmd(_start+0x29) [0x462289]] 3: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f19d54fc830]] 2: [./build/app/testpmd(main+0x8a3) [0x466193]] 1: [./build/app/testpmd(__rte_panic+0xd6) [0x4efaa6]] Aborted This problem appears with commit 66cc45e293ed ("mem: replace memseg with memseg lists") however the root cause is introduced by a prior patch. [1] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Fixes: c44d09811b40 ("eal: add shared indexed file-backed array") Cc: Anatoly Burakov Signed-off-by: Adrien Mazarguil Acked-by: Anatoly Burakov --- lib/librte_eal/common/eal_common_fbarray.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/eal_common_fbarray.c b/lib/librte_eal/common/eal_common_fbarray.c index f65875dd9..11aa3f22a 100644 --- a/lib/librte_eal/common/eal_common_fbarray.c +++ b/lib/librte_eal/common/eal_common_fbarray.c @@ -173,7 +173,10 @@ find_next_n(const struct rte_fbarray *arr, int start, int n, bool used) */ /* count leading zeroes on inverted mask */ - clz = __builtin_clzll(~cur_msk); + if (~cur_msk == 0) + clz = sizeof(cur_msk) * 8; + else + clz = __builtin_clzll(~cur_msk); /* if there aren't any runs at the end either, just continue */ if (clz == 0)