From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 93F71A04A6 for ; Fri, 17 Dec 2021 18:50:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 78DF140040; Fri, 17 Dec 2021 18:50:32 +0100 (CET) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by mails.dpdk.org (Postfix) with ESMTP id 7B0CB40040 for ; Fri, 17 Dec 2021 18:50:31 +0100 (CET) Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id D63AA3FFD0 for ; Fri, 17 Dec 2021 17:50:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1639763428; bh=/GvvpGVoA8ad/IHy9ccmYJ6QXeCUWaHbEd5VgLHqzt0=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gABmb4ZoCULwgZleG7BL0Jex7WraJC3fARyhOnCP3i5PAa8FS6xgNmRn+8QqcuwNi Vx3gDyXbiEn8n6Xg93IkbwcBD+1MfH8lv956R5kd45lSydXg4lXDN2HzXfGPKFjPJe vA+Zowvhmu/fIAiIHRMt3hiIcm2x3H68Q+WnlimHitE9AddLXqPCUrOvR1zdoYRX7o A6aQ8ViIB0f30gRrb4PFYxgcnXEa28r6V798HWlCItvtpgrroE1yztSENFjg0Ocv3E VgWwZknZmY1iN0DsSQTD+XoNRo76fm5PBYBdpwoybEtFkvSdgLNPsyZIdc/1C8VRbg Cl+hV8LzYuJpw== Received: by mail-qt1-f199.google.com with SMTP id a26-20020ac8001a000000b002b6596897dcso3122412qtg.19 for ; Fri, 17 Dec 2021 09:50:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/GvvpGVoA8ad/IHy9ccmYJ6QXeCUWaHbEd5VgLHqzt0=; b=v2gIWM3QhPfb9GUaewKtzBemmhpkXoGkUeNVpEkgpdAQvPcrbbsnoNRHnBHkJVjnyp Dr9udo/BrpHpImsiLJddjolPeSZwihPthSSTudcZOXtiNjxQqAMyrZR+FOexjvBtbaJe obp4HHn68L/n72r2gOSoDwagrUruRmJh96C9c4iW3nbQE/3Zg/5csPw1GJQ3XAOZWd4C kLJHOlRGTE/tq+FYKhFqmdRysfPsqcOidJ+ojnrBhdS5hf41MhvhHPPJdhLXdu/xhqhH M3wqXZsB7TmR53btpaqr7mIHRBX8VXmgAMnLkbix1ocdGJTROU4gejMA98XCpN6VW+F8 oxxQ== X-Gm-Message-State: AOAM530QfSsF6BnuMQ+lKoPYq8O9BwHWTpy4U6u/iNzqQIovNG8P/eMI X6SN/Kl1xMqVSpoYwqQ8EpowKfN6sk/yPqf+cl7f1DcELG72iFxaUxxX1YQLoWlS1S1psjCJe/L 2DN6lpzD4tCYry7SEbWKE/7vqJ3DHDIKwD5CQRXyE X-Received: by 2002:a05:6214:23ca:: with SMTP id hr10mr3462677qvb.78.1639763427875; Fri, 17 Dec 2021 09:50:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNEcXqfrna489djV+j/YXJGwLiVGVVPgxw1lTeIxxSt7kyNYO4NZ6iDM4nr9KaMWCKE3F6k4ZdMXB7dFsbTps= X-Received: by 2002:a05:6214:23ca:: with SMTP id hr10mr3462663qvb.78.1639763427636; Fri, 17 Dec 2021 09:50:27 -0800 (PST) MIME-Version: 1.0 References: <20211217095124.3500864-1-christian.ehrhardt@canonical.com> <579800f9f68738b114417f807c3a539fd96a093b.camel@debian.org> In-Reply-To: From: Christian Ehrhardt Date: Fri, 17 Dec 2021 18:50:01 +0100 Message-ID: Subject: Re: [PATCH] cryptodev: fix stringop-overflow build failure with gcc 10 To: Luca Boccassi Cc: "Richardson, Bruce" , "stable@dpdk.org" , "ktraynor@redhat.com" , Thomas Monjalon , "Yigit, Ferruh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Fri, Dec 17, 2021 at 4:02 PM Luca Boccassi wrote: > > On Fri, 2021-12-17 at 12:09 +0000, Richardson, Bruce wrote: > > > > > -----Original Message----- > > > From: Luca Boccassi > > > Sent: Friday, December 17, 2021 12:01 PM > > > To: christian.ehrhardt@canonical.com; stable@dpdk.org > > > Cc: Richardson, Bruce ; ktraynor@redhat.c= om; > > > Thomas Monjalon ; Yigit, Ferruh > > > > > > Subject: Re: [PATCH] cryptodev: fix stringop-overflow build failure w= ith > > > gcc 10 > > > > > > On Fri, 2021-12-17 at 10:51 +0100, christian.ehrhardt@canonical.com > > > wrote: > > > > From: Christian Ehrhardt > > > > > > > > 19.11 LTS releases started to fail to build in some newer releases > > > > due to newer gcc-10 compilers available. Those are mostly false > > > > positives [1][2] and to some extend covered by the already present > > > > backports of "4990929c60 eal/ppc: ignore GCC 10 stringop-overflow > > > > warnings" and "df17bcb43b eal/x86: ignore gcc 10 stringop-overflow > > > > warnings". > > > > > > > > But the combination of 19.11 and gcc 10.3.0 and LTO this can still > > > > exposes the issue. > > > > > > > > [ 549s] In function =E2=80=98_mm_storeu_si128=E2=80=99, > > > > [ 549s] inlined from =E2=80=98rte_memcpy_generic=E2=80=99 > > > > at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:508:2, > > > > [ 549s] inlined from =E2=80=98rte_cryptodev_sym_session_set_us= er_data=E2=80=99 > > > > at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:882:10: > > > > [ 549s] /usr/lib/gcc/x86_64-linux-gnu/10/include/emmintrin.h:727:8= : > > > > error: writing 16 bytes into a region of size 0 > > > > [-Werror=3Dstringop-overflow=3D] > > > > [ 549s] 727 | *__P =3D __B; > > > > [ 549s] | ^ > > > > [ 549s] ../lib/librte_cryptodev/rte_cryptodev.c: > > > > In function =E2=80=98rte_cryptodev_sym_session_set_user_data=E2= =80=99: > > > > [ 549s] ../lib/librte_cryptodev/rte_cryptodev.h:984:4: note: > > > > at offset 0 to object =E2=80=98sess_data=E2=80=99 with size 0 dec= lared here > > > > [ 549s] 984 | } sess_data[0]; > > > > [ 549s] | ^ > > > > > > > > The problem is that in this combination only at link time (LTO) > > > > the compiler will (false-)detect the problematic size of the target > > > > structure and break. To make things worse [3] fixed this problem > > > > for the same issue at actual build time, but the pragma has no > > > > effect at link time nor are any werror settings passed to the > > > > linker. > > > > > > > > For affected compilers set -Wno-stringop-overflow globally for > > > > the linker stage to avoid this breaking the build in any place. > > > > > > > > Buzilla ID: 908 > > > > > > > > [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94335 > > > > [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92955 > > > > [3]: https://github.com/DPDK/dpdk/commit/b5b3ea803e47 > > > > > > > > Signed-off-by: Christian Ehrhardt > > > > --- > > > > config/meson.build | 8 ++++++++ > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/config/meson.build b/config/meson.build > > > > index 4007b8f37c..25dec320ba 100644 > > > > --- a/config/meson.build > > > > +++ b/config/meson.build > > > > @@ -143,6 +143,14 @@ if numa_dep.found() and cc.has_header('numaif.= h') > > > > dpdk_extra_ldflags +=3D '-lnuma' > > > > endif > > > > > > > > > > > > +# Some false positives can trigger at LTO stage, so this warning n= eeds > > > to be > > > > +# disabled on the linker as well for gcc 10. > > > > +# Fixed in gcc-11 and not present > > > +# https://bugs.dpdk.org/show_bug.cgi?id=3D908 > > > > +if cc.get_id() =3D=3D 'gcc' and cc.version().version_compare('>=3D= 10.0') and > > > cc.version().version_compare('<11.0') > > > > + add_project_link_arguments('-Wno-stringop-overflow', language: 'c= ') > > > > +endif > > > > + > > > > has_libfdt =3D 0 > > > > fdt_dep =3D cc.find_library('libfdt', required: false) > > > > if fdt_dep.found() and cc.has_header('fdt.h') > > > > > > Sounds reasonable to me. Is it possible to detect that LTO is used, t= o > > > further restrict when this is applied? > > > I haven't found one as it could be enabled as default built into the compiler even when not present in cflags. And parsing cflags would already be brittle. Therefore I'm in favor of just the version check as I submitted it. > > Does it really matter that much? This is for backport only, so won't ap= ply for main tree, meaning that all backported patches will have been alrea= dy checked with the setting enabled on the mainline. Therefore, I would loo= k to not bother trying to limit the impact of the flag much, and just enabl= e it in the most convenient manner. > > > > /Bruce > > Just thinking about coverage for future backports, but it's not too > important > > -- > Kind regards, > Luca Boccassi --=20 Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd