From patchwork Fri Apr 13 15:39:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrien Mazarguil X-Patchwork-Id: 38056 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 3B83E1C68E; Fri, 13 Apr 2018 17:39:16 +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 A80D41C67A for ; Fri, 13 Apr 2018 17:39:14 +0200 (CEST) Received: by mail-wr0-f193.google.com with SMTP id v60so5324646wrc.7 for ; Fri, 13 Apr 2018 08:39:14 -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:mime-version:content-disposition; bh=ErsybeCMz1go6YaCuaNCAVVJzFGxiPCOVx9phcKcZBs=; b=CWneMe49ANgLBNy9F6CnnGC2xxVfe+DOv+M57F6fSU+PfvjI2ymP/BkhliDzBbvy79 MKqmuX+4yTQUVS0+VSX7Inp1/7DTgRYbNHv79zhqRcJZCgJ5otSvJUVIwxvLW49A31ch fMRmuEzo4tCt7q3HSavH61A1EFlh8tX4o7m6yJrWfwts4kGvOfYLN3Fwe0acXwf77hu4 J4Yh1rGehFBW6jF9E7687XpToRnTCSm6lgViUkZFnj/yLxEWHhg8tMbHElWVzCP2ZNPi g/0WE5En0KaljPs9Hs2bCnIcTsNgNejPsaEDtnu0MX4BhZFK3gBz4a6gEmB5aptbQ29m b6uQ== 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:mime-version :content-disposition; bh=ErsybeCMz1go6YaCuaNCAVVJzFGxiPCOVx9phcKcZBs=; b=Hkapy9McXU7MUav3/6YroDF8mcqkSyJktAyMACd93WVEEYBlRQATcCkxM8+6z98Lw6 5aFv3VsCy0HtAMzNmyP0mu/WyCVPdlWkNZ7d1c/5Yc5s4alUC+Mlf6QMlS/gJuw6r/vf RE6wroK1ruVSJcOTgW4czGNZQTtO6Eurnbu/bK48TjpctygXNRgRUD5sbFI8SC/acXGL FBmWN+eKC5f2nDxgx5Z6iSuurv57qB/7BQKw96G0CYKBccCrge7m7FB4gEtZOnE6NyWV YYiDm00Uc4aU68ayZeBmqHCPBszKjjxpJl3kcebCcA6AMfjsmp0OxCvfZrFz4WR/Ibfz PcEw== X-Gm-Message-State: ALQs6tDbi6gJDb9C7+7yMKbyCG5unvba+u+lZ7ibjrt4+ohwQKiF+OHo t7E2CqEmaBNEDIOGAdSyoJXNxrXE X-Google-Smtp-Source: AIpwx48xXzJ83ca5JJtRjn6pwuijXb6OkGtBTwpZprNTYjJnAetsns7u53/8AezG4FyIWey5TfeGFw== X-Received: by 10.223.160.26 with SMTP id k26mr4406199wrk.35.1523633954412; Fri, 13 Apr 2018 08:39:14 -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 d9sm2821637wmh.38.2018.04.13.08.39.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 08:39:13 -0700 (PDT) Date: Fri, 13 Apr 2018 17:39:00 +0200 From: Adrien Mazarguil To: Anatoly Burakov Cc: dev@dpdk.org Message-ID: <20180413153749.28208-1-adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Disposition: inline X-Mailer: git-send-email 2.11.0 Subject: [dpdk-dev] [PATCH 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 --- 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)