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 87BECA0548; Fri, 24 Sep 2021 17:13:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 147C14126F; Fri, 24 Sep 2021 17:13:58 +0200 (CEST) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by mails.dpdk.org (Postfix) with ESMTP id CB8D640041 for ; Fri, 24 Sep 2021 17:13:56 +0200 (CEST) Received: by mail-pg1-f176.google.com with SMTP id w8so10168000pgf.5 for ; Fri, 24 Sep 2021 08:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=m5RUPU/+lTPzHMw1YBOagnYQ14+eIZnOURXAwCen3R8=; b=imUGDYe1+hPYMOyrtuKk8jk7dNVAR7Uj5z/LfQ0XFGML01aYm5lfoH7UYQV3vh6s/N hIR28Y2sLkfoMxHwLUizmCD/ndNo2L6QbTcg7xVsQcCinQ1ffIJ+Yw+NGLHiG8t8mxpj 3C3P42V9JARwj/v/aH6ONDfo7IR28am6QueNqiQuSQ4Sj/zReYPmNzyJIDT5k5gQx1sM tFh977lKYwzsnEafGjvlIaWpseKgIVOECB/CB9BX8qWvIQMZuE4TgNNLqnn+PhAl3dXX 5Xzwi131AxeFLMnljDE8xBeTF4Xz94elcRjh1/tLdKtSGWu7K2rHtnfRkv/yZWWX41TC aPNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=m5RUPU/+lTPzHMw1YBOagnYQ14+eIZnOURXAwCen3R8=; b=X+viGRWJe4jmoZh0U8EGLaKYDBOqbL8y9Jeyxcrk3lmdClacJkbslQ2kOeBbSLmla/ mFTSnjmBZCJ0AbVNaDBIoG/Spl8IPi/cQPFNs2yXX3XoUMghAeSDVZ6hNfOGd6TVKV4A YWLvm/I/oaghxNUZW9y5fWcaLcFFSqPpucA+dB4Lu615/WD870EQIJ1k0FDNni6HyIee YbsTEccPGSEHoudgEMhQl2U2uM+svky6SMgB8byB31KT6n/Udv5lY9ds85zb3KEs6YrS CE7edfY8dxYjD6FMVx71vvwCYsWwwITCOkyRMWq9dwOxrzHfpP4/p4Stn5ImMGBkXN9K HdCg== X-Gm-Message-State: AOAM532ev+WYX3ljdRfAoix6JHLdQpzEpm5FfzLQ5leHGENe6jYxmg3u DdDOE17d+OSf076svDBKdIPdIQ== X-Google-Smtp-Source: ABdhPJzutJuVcwj2lhjhrVCgXwjn6wpq79E2X5dSJpRtgT9FmXzuBr1npCk5nNG7AQ0dlj3cSVGHUQ== X-Received: by 2002:a63:450:: with SMTP id 77mr2893835pge.438.1632496435852; Fri, 24 Sep 2021 08:13:55 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id d12sm6818661pgf.19.2021.09.24.08.13.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Sep 2021 08:13:55 -0700 (PDT) Date: Fri, 24 Sep 2021 08:13:52 -0700 From: Stephen Hemminger To: Olivier Matz Cc: zhihongx.peng@intel.com, anatoly.burakov@intel.com, konstantin.ananyev@intel.com, dev@dpdk.org, xueqin.lin@intel.com Message-ID: <20210924081352.5f587f2a@hermes.local> In-Reply-To: References: <20210924021630.1291343-1-zhihongx.peng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 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 Fri, 24 Sep 2021 11:52:33 +0200 Olivier Matz wrote: > Hi Zhihong, > > On Fri, Sep 24, 2021 at 02:16:29AM +0000, zhihongx.peng@intel.com 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. > > > > By referring to its implementation algorithm > > (https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm), > > enable heap-buffer-overflow and use-after-free functions on dpdk. > > DPDK ASan function currently only supports on Linux x86_64. > > Support other platforms, need to define ASAN_SHADOW_OFFSET value according > > to google ASan document. > > > > Here is an example of heap-buffer-overflow bug: > > ...... > > char *p = rte_zmalloc(NULL, 7, 0); > > p[7] = 'a'; > > ...... > > > > Here is an example of use-after-free bug: > > ...... > > char *p = rte_zmalloc(NULL, 7, 0); > > rte_free(p); > > *p = 'a'; > > ...... > > > > If you want to use this feature, > > you need to add below compilation options when compiling code: > > -Dbuildtype=debug -Db_lundef=false -Db_sanitize=address > > "-Dbuildtype=debug": This is a non-essential option. When this option > > is added, if a memory error occurs, ASan can clearly show where the > > code is wrong. > > "-Db_lundef=false": When use clang to compile DPDK, this option must > > be added. > > > > Note: > > a) The issue of ASan wild pointer is that dpdk ASan tool is not fully > > adapted to google ASan. For example: Address 0x7fe2ffafa240 is a wild > > pointer. > > b) Centos needs to install libasan separately. > > c) If the program uses DPDK cmdline, when a memory bug occurs, need > > to execute the "stty echo" command. > > > > Signed-off-by: Xueqin Lin > > Signed-off-by: Zhihong Peng > > Thank you for this patch, this looks quite useful. > > Do you know what is the performance impact of enabling ASan? Purely application dependent. In the Linux kernel on x86 it is around 10% according to report by Google. My observation is that for DPDK (for malloc/free etc, not this patch) ASAN causes large impact on Arm like 90% slower. But our application is CPU intensive. > Do you think a similar approach could be applied to mempools?