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 C774CA0C46; Mon, 20 Sep 2021 21:41:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B22A40DF7; Mon, 20 Sep 2021 21:41:29 +0200 (CEST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mails.dpdk.org (Postfix) with ESMTP id 8CE3B40DF5 for ; Mon, 20 Sep 2021 21:41:28 +0200 (CEST) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 18KJG2vW015015; Mon, 20 Sep 2021 15:41:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=subject : to : cc : references : from : message-id : date : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=GOuCEpVsUeqML3Lk0RZ40EfscCODKG+IvU8YQo8wHfM=; b=kadgYszOA5olJiT6BtX7eD09LECAvjXVUL6wNbmR1EXd0yPUTyS4UXY1oonuWyigMUXl QdcQA3i81lL9Uv4obMdKzigGS/oU8/CCGmUcRr3eNjzH01PFtl+HOIzm+wmNqqU1Sc7P fVZMseFbyd+5DnbPtB66CeL2iuKbfSu4052ruw06fRY/HJNNp7KKagGlylICGa7gvkG2 z2Q/mOVul+TbyfXYOFFVKdbCugh+ba06K6eqMpNhJwo7fUbWudzc2QPOouvG2x8b+e5K KjEMFtjGn9ML/F3pxWJD0kVmjAS4PxBz4vxCv6o1EIplB5+VZ+122wosVisalyklFbKc Wg== Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0b-001b2d01.pphosted.com with ESMTP id 3b5w22kwa3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Sep 2021 15:41:27 -0400 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 18KJN8eS003019; Mon, 20 Sep 2021 19:41:26 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma03wdc.us.ibm.com with ESMTP id 3b57r9yj71-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Sep 2021 19:41:26 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 18KJfQcK37159222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Sep 2021 19:41:26 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 49A002805C; Mon, 20 Sep 2021 19:41:26 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 95D6B2805E; Mon, 20 Sep 2021 19:41:25 +0000 (GMT) Received: from Davids-MBP.randomparity.org (unknown [9.211.49.26]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 20 Sep 2021 19:41:25 +0000 (GMT) To: "Peng, ZhihongX" , "Burakov, Anatoly" , "Ananyev, Konstantin" , "stephen@networkplumber.org" Cc: "dev@dpdk.org" , "Lin, Xueqin" References: <20210910020147.148019-1-zhihongx.peng@intel.com> <61dd38ed-b570-d7d5-e839-1f845e28e932@linux.vnet.ibm.com> From: David Christensen Message-ID: <261b1c48-3794-1b42-a794-be76819049ab@linux.vnet.ibm.com> Date: Mon, 20 Sep 2021 12:41:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: vHxjZ-LBbVK3HIvBiKqJXv39jmbqOtNl X-Proofpoint-GUID: vHxjZ-LBbVK3HIvBiKqJXv39jmbqOtNl Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-20_07,2021-09-20_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001 definitions=main-2109200112 Subject: Re: [dpdk-dev] [PATCH] Enable AddressSanitizer feature 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 9/18/21 12:21 AM, Peng, ZhihongX wrote: >> -----Original Message----- >> From: David Christensen >> Sent: Saturday, September 18, 2021 4:51 AM >> To: Peng, ZhihongX ; Burakov, Anatoly >> ; Ananyev, Konstantin >> ; stephen@networkplumber.org >> Cc: dev@dpdk.org; Lin, Xueqin >> Subject: Re: [dpdk-dev] [PATCH] Enable AddressSanitizer feature on DPDK >> >>>>> 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": Display code information when coredump occurs >>>>> in the program. >>>>> "-Db_lundef=false": It is enabled by default, and needs to be >>>>> disabled when using asan. >>>> >>>> On initial inspection, it appears ASAN functionality doesn't work >>>> with DPDK on PPC architecture. I tested the patch with several >>>> compiler versions (gcc >>>> 8.3.1 from RHEL 8.3 through gcc 11.2.1 from the IBM Advanced >>>> Toolchain 15.0) and observed the following error when running testpmd >> with ASAN enabled: >>>> >>>> AddressSanitizer:DEADLYSIGNAL >>>> >> ========================================================== >>>> ======= >>>> ==49246==ERROR: AddressSanitizer: SEGV on unknown address >>>> 0x0000a0077bd0 (pc 0x000010b4eca4 bp 0x7fffffffe150 sp 0x7fffffffe150 >>>> T0) ==49246==The signal is caused by a UNKNOWN memory access. >>>> #0 0x10b4eca4 in >> asan_set_shadow ../lib/eal/common/malloc_elem.h:120 >>>> #1 0x10b4ed68 in >> asan_set_zone ../lib/eal/common/malloc_elem.h:135 >>>> #2 0x10b4ee90 in asan_clear_split_alloczone >>>> ../lib/eal/common/malloc_elem.h:162 >>>> #3 0x10b51f84 in malloc_elem_alloc >>>> ../lib/eal/common/malloc_elem.c:477 >>>> ... >>>> >>>> Can you incorporate an exception for PPC architecture with this patch >>>> while I look into the problem further? >>>> >>>> Dave >>> >>> We do not have a ppc platform, so there is no adaptation. >>> doc/guides/prog_guide/asan.rst has stated that we currently only >>> support Linux x86_64. You can adapt according to the following documents, >> the main work is to modify the base address according to the platform. >>> Documents: >>> https://github.com/google/sanitizers/wiki/AddressSanitizer >>> https://github.com/llvm/llvm-project/tree/main/compiler-rt >> >> Understand you don't have such a platform. I looked into it and suggest the >> following change in lib/eal/common/malloc_elem.h: >> >> #define ASAN_SHADOW_GRAIN_SIZE 8 >> #define ASAN_SHADOW_SCALE 3 >> #ifdef RTE_ARCH_PPC_64 >> #define ASAN_SHADOW_OFFSET 0x020000000000 #else #define >> ASAN_SHADOW_OFFSET 0x00007fff8000 #endif >> #define ASAN_MEM_FREE_FLAG 0xfd >> #define ASAN_MEM_REDZONE_FLAG 0xfa >> #define ASAN_MEM_TO_SHADOW(mem) (((mem) >> >> ASAN_SHADOW_SCALE) + >> ASAN_SHADOW_OFFSET) >> >> >> This resolves the segmentation error I receive. >> >> Dave >> > > Great, good information for dpdk asan tool. Because we can't do many tests, > so when this patch is merged into the main line, you can submit the ppc > architecture patch. If your argument is that this is x86 only then please ensure it can't be enabled on non-x86 platforms such as ARM and PPC. I can then easily submit a follow-on patch to enable for PPC. As the patch currently stands it enables ASAN on a non-tested platform and provides an unexpected error for some users when it can easily be avoided. I'd advise not accepting the patch as currently presented. Dave