From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 048F5C433EF for ; Wed, 13 Oct 2021 07:59:45 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 89F6460E54 for ; Wed, 13 Oct 2021 07:59:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 89F6460E54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9151C41175; Wed, 13 Oct 2021 09:59:43 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id A8F1741162 for ; Wed, 13 Oct 2021 09:59:41 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10135"; a="288246841" X-IronPort-AV: E=Sophos;i="5.85,370,1624345200"; d="scan'208";a="288246841" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2021 00:59:40 -0700 X-IronPort-AV: E=Sophos;i="5.85,370,1624345200"; d="scan'208";a="442184344" Received: from batkinso-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.25.241]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 13 Oct 2021 00:59:33 -0700 Date: Wed, 13 Oct 2021 08:59:30 +0100 From: Bruce Richardson To: David Marchand Cc: Zhihong Peng , "Burakov, Anatoly" , "Ananyev, Konstantin" , Stephen Hemminger , dev , Xueqin Lin , Thomas Monjalon Message-ID: References: <20210924100310.4278-1-zhihongx.peng@intel.com> <20210930052724.195414-1-zhihongx.peng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v6 1/2] Enable ASan for memory detector on DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On Thu, Sep 30, 2021 at 10:20:00AM +0200, David Marchand wrote: > Hello, > > I see v6 is superseded in pw, I have been cleaning my queue... maybe my fault. > > > On Thu, Sep 30, 2021 at 7:37 AM wrote: > > > > From: Zhihong Peng > > > > AddressSanitizer (ASan) is a google memory error detect > > standard tool. It could help to detect use-after-free and > > {heap,stack,global}-buffer overflow bugs in C/C++ programs, > > print detailed error information when error happens, large > > improve debug efficiency. > > > > `AddressSanitizer > > ` (ASan) > > is a widely-used debugging tool to detect memory access errors. > > It helps detect issues like use-after-free, various kinds of buffer > > overruns in C/C++ programs, and other similar errors, as well as > > printing out detailed debug information whenever an error is detected. > > This patch mixes how to use ASan and instrumenting the DPDK mem allocator. > > I would split this patch in two. > > The first patch can add the documentation on enabling/using ASan and > describe the known issues on enabling it. > I'd find it better (from a user pov) if we hide all those details > about b_lundef and installation of libasan on Centos. > > Something like (only quickly tested): > > diff --git a/config/meson.build b/config/meson.build > index 4cdf589e20..7d8b71da79 100644 > --- a/config/meson.build > +++ b/config/meson.build > @@ -411,6 +411,33 @@ if get_option('b_lto') > endif > endif > > +if get_option('b_sanitize') == 'address' > + asan_dep = cc.find_library('asan', required: true) > + if (not cc.links('int main(int argc, char *argv[]) { return 0; }', > + dependencies: asan_dep)) > + error('broken dependency, "libasan"') > + endif > + add_project_link_arguments('-lasan', language: 'c') > + dpdk_extra_ldflags += '-lasan' > +endif > + > if get_option('default_library') == 'both' > error( ''' > Unsupported value "both" for "default_library" option. > > > Bruce, do you see an issue with this approach? > Apologies for delayed reply on this. No issue with this approach on my end, seems reasonable. Just watch out that b_sanitize can have "address,undefined" as a possible value, so if we want to support that, we can't just check directly for the literal string "address" > > Then a second patch adds the rte_malloc instrumentation, with a check > at configuration time. > > endif > add_project_link_arguments('-lasan', language: 'c') > dpdk_extra_ldflags += '-lasan' > + if arch_subdir == 'x86' > + asan_check_code = ''' > +#ifdef __SANITIZE_ADDRESS__ > +#define RTE_MALLOC_ASAN > +#elif defined(__has_feature) > +# if __has_feature(address_sanitizer) > +#define RTE_MALLOC_ASAN > +# endif > +#endif > + > +#ifndef RTE_MALLOC_ASAN > +#error ASan not available. > +#endif > +''' > + if cc.compiles(asan_check_code) > + dpdk_conf.set10('RTE_MALLOC_ASAN', true) > + endif > + endif > endif > Apologies, but I haven't been tracking this set in much detail. Do we really need this second configuration check? Should it, or could it, be merged into the check above for the asan library presence? /Bruce