From patchwork Fri Apr 13 15:56:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrien Mazarguil X-Patchwork-Id: 38059 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 310D11C684; Fri, 13 Apr 2018 17:56:40 +0200 (CEST) Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by dpdk.org (Postfix) with ESMTP id 36C601C677 for ; Fri, 13 Apr 2018 17:56:38 +0200 (CEST) Received: by mail-wr0-f196.google.com with SMTP id u11so9358241wri.12 for ; Fri, 13 Apr 2018 08:56:38 -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=ErsybeCMz1go6YaCuaNCAVVJzFGxiPCOVx9phcKcZBs=; b=rnYjGD3Fxf56gs4aV1P9WJ7RuIXYZtl5teuxl45fBEAjPiq5UiWlEqSPb8YtETxzrs PSRsjjcsRdaB9OEmE29cx8sZy7dOIe8iP0Kv/PDLcWHkmG4Q41VxDKmjmFFo0JG4WXJE OcmCLcs37mRpdj7fBDi18/RJIGHBAfO2y5kveNL09gWrD+FXlf//7iCxfNhnc6mzXVFQ rjZRzdQsW+2CeEWwfk0kJ3lpgxtvimpKNn3anTAGECmeIB0Xn5iGhXEqXN/tpLjq/vdq m8o1wZ11LBcT2O/n1rGO/xC4rRdSi5RaF8MfUvOxWcKpyeqvyvJGSX1e7kl3R5aU1KK+ K7aQ== 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=ErsybeCMz1go6YaCuaNCAVVJzFGxiPCOVx9phcKcZBs=; b=LbgIYzMWIsnrAn6jBTQxz0UHmAy6hfMYoP0cTCf48X7Pcn32u6kPNPpLgRrpzH6ozP V0kVlYi6rJ3FhP5veo6rShnQFPORgLjRtN9/Z6VELtRnncy1qQDs4g75iy7vsuw/rWRT g/AuZbeNdVdLpb5uSue9nMxjK4HRs+WqZj27xNuICGgxkWYCT77dMXFYW8uZby/9QpIY mNs4Mi4uLq3JYU3OReMZqErSDDLWg5NSgQvq/hEmxrYDnnKl83bziDBbNKSxsHsWbpnh TqiOpoLsgkEk9HPsEkj9Jkmal0YsYJuP5ouuTHWxDD9WCOAhCbpstrPIboExm9CIiZOX C4HA== X-Gm-Message-State: ALQs6tBnWsgbj1sAYX1+N2MFZbRSF2zIlRhyvcyInCDsdrwdBTSL31mq czk3q0iQF9SObZt6cfJppYe9V4U8 X-Google-Smtp-Source: AIpwx4/wz2XdDPc+ZaMfu5nHTByB5ZRzdtgCD49IfceWCTJit1VGEpBSRnmTc+Ap5xEQwGix5Bx7gg== X-Received: by 10.28.8.13 with SMTP id 13mr279908wmi.9.1523634997957; Fri, 13 Apr 2018 08:56:37 -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 r75sm1862200wmf.34.2018.04.13.08.56.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 08:56:37 -0700 (PDT) Date: Fri, 13 Apr 2018 17:56:24 +0200 From: Adrien Mazarguil To: Anatoly Burakov Cc: dev@dpdk.org Message-ID: <20180413155417.29643-1-adrien.mazarguil@6wind.com> References: <20180413153749.28208-1-adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180413153749.28208-1-adrien.mazarguil@6wind.com> X-Mailer: git-send-email 2.11.0 Subject: [dpdk-dev] [PATCH v2 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)