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 4E7E6A034C; Tue, 26 Apr 2022 14:55:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E2D340E78; Tue, 26 Apr 2022 14:55:08 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id D015B40C35; Tue, 26 Apr 2022 14:55:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650977706; x=1682513706; h=message-id:date:subject:from:to:cc:references: in-reply-to:content-transfer-encoding:mime-version; bh=9d6+kNmDWQYT7mk/v2/tpa9ol03YcdbPX5klDICefxU=; b=ETOyI/5vh2Liz8FhWaYz3FmP1avdKnxLtQoxig6/aXKKqJEO+t+2GgxK sMVYgOFzTMH4R4UJuJ5yWEtWlx3cvxVyjtk1EP/D1l5v7EhY4Z46gQA4v 9DDMKdPHyvl7kw83taJ8BL0ztB02WoDy0Lu5kKiFBTQ7XIQkMdGWvtjjV fFIj5NNiA99qvlaTP6P6AnZTv7YcMSUZytO/3GOnhyJtpt5EqFddRrMT8 5eYO1FMDxd7jw8wr7wpOPfQwKc0slIgJiN3x8ePo0m+GUzA0gOSxI9vEl yU6UekwNACRuoBasCfcd14xWW0OVWLdF4wBioDUlY9neIA0MLzIpIf441 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="264410382" X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="264410382" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 05:54:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="532645810" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga006.jf.intel.com with ESMTP; 26 Apr 2022 05:54:47 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 26 Apr 2022 05:54:46 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Tue, 26 Apr 2022 05:54:46 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.105) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Tue, 26 Apr 2022 05:54:44 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DrWNFL4VdqGKpZVI5bC7EjAF1nBjVJxFrh+ZRhZuV0xQQ2bUOPxjCMuquYDTUbBuorczX5h/3zN5py6GXgpoPQ0gRbUn0KvhSwVXYQcScNe4mCvpIKj+HYfmwADs0vLW5TyDHc2LERlq0AbYVCil8c9BQDXdI+q3oBA7h0BIb+DTGQuFoh6EZpPRmAJQV25aEX2t7dpn3iUvVvJdd4jzSKVpq3qpWvg4vg04viveTfhrI5+DfvntvMADlLs8ao3Jr+ZpwigCsczLZzxgSgpPhpIEnIgXpqG7Z0RjGDTNAjYKY/2xpGzG0DCCb3VIwUvbjA800+RW9YCq3Xn672steg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QRNWzkigFp2HcH4h/SSAUMOFkv3dLSxvPODpaPnMRsU=; b=deW8RXPOUMfc6zCPyhTd8cGrjp6q4+nEbMoWkPhu1RJEtoFdvzYFev8dkg3yoKsC/gDoW+dW+BzU6IYhxbLosegjLxk6AbbIisCWLOdyFVRcwws1SLc/H24AhjiUeQNVv7C1oPFukQNzvI1cOqsH0IL4RKvdY0d4kAeSJ+qn5VHzVdK02KYuwQXkCuqyfzCW9AfN7v7JT38h/sDYSb7PShybHe4pymIdrd4HjR6gg7zD2T5Zfp8vBvh7qSfPFC+pwdoDm5PTS8i9s1AnXBro5pFYCmVFHWD+PEr2WAuNAnEsu7YsjyagQqzg7YekYMGi++3R72UqxDUsKFEEuBkVIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) by BN6PR11MB1362.namprd11.prod.outlook.com (2603:10b6:404:3c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.14; Tue, 26 Apr 2022 12:54:42 +0000 Received: from PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::28af:8ec5:1817:1af1]) by PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::28af:8ec5:1817:1af1%3]) with mapi id 15.20.5186.021; Tue, 26 Apr 2022 12:54:42 +0000 Message-ID: <249b5c3e-513b-af96-399a-01d60ff93d26@intel.com> Date: Tue, 26 Apr 2022 13:54:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.8.1 Subject: Re: [PATCH 2/3] mem: fix ASan shadow for remapped memory segments Content-Language: en-US From: "Burakov, Anatoly" To: David Marchand CC: dev , "Mcnamara, John" , "Dmitry Kozlyuk" , dpdk stable , Xueqin Lin References: <20220415173127.3838-1-david.marchand@redhat.com> <20220415173127.3838-3-david.marchand@redhat.com> <419bb7fc-cb04-10cf-a40a-5dba39323f9e@intel.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0297.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a5::21) To PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1bc07891-90cb-4122-dc4f-08da2783ee1c X-MS-TrafficTypeDiagnostic: BN6PR11MB1362:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IxgUy+1Pob9T/S44nabFn/XQWDgxQl3KoL0PTjgz73dso4JAzn4h9uNkyNQHcQnxG1hCIkSJ+UZKkAACLpty9DRAZVp2KjZRObBkHqylVvlZWvxVET2sAe/jCBfVVxBmKnUSQ8juJiBWOiygMRVXx9OaYBAdo4wepCvNEtyGzk0T6q7EHWyRdHw7+54I7N/Qv1LolepL5FWNUpa8hgRnW2SGA4KVWyZPaELofOZr+fHuonz7Iq+mbZW4cXWKZcPsWKt3LgrlAIfOhTzPg3a+pvOSnKzF6d0XoPXz15fA8ec4bpPHsk1CIRzqMnjm5IT2mpRQhpiRnv2YzZ4fsgflMUJx5MWu7OGCz1BqAn8U8Kjo3xCPu+FwmuEIqp1oITnNH+CWl2FqFh5X7kTfiacr3ZVXK2U+bJh2vrnT6ki9NQu7Nj8+1ajTeV78NXAogsEkeDmFsYYRchb97/P6nxXxn0+im5kcHtQX8HhC7NBiSi+lOplRGctMgGv5Pw5khEIo91xvNu6yagzphKigpL8jqPxz7zdAHbJ1uguSvCgi78e+DVByfd6mBi6RJKaTIsk1IC2N1Vq3jx8mfWhYRHbp9A2m8em3jHBM8P+G53joq7PjUsbL7tXES/s3tx6TIVk1DfZyTyRG2Fwsr+tmCgh0IIaHDeeJaJDsOTYCDpha5mG1g0z2xfBB7n43YRDp9ydGciJx2V4PbZK/psTPIogdmpQ6CPR4XezPy8eQgrXdK40= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5093.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(6486002)(107886003)(86362001)(6506007)(38100700002)(66556008)(53546011)(66476007)(31696002)(26005)(36756003)(83380400001)(54906003)(2616005)(186003)(6666004)(6512007)(508600001)(82960400001)(2906002)(66946007)(5660300002)(8936002)(8676002)(6916009)(316002)(4326008)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T2hkRFpmMWlFaWxuQVkrQVdTblQ0YXF6cmlYZkZ0aG5NbHoyWHhKWFJRYXZ4?= =?utf-8?B?R09hOTZ2czk5MmZOQmN0Rm4xNXRZTU9HVm5jVVlNREFhU0Nkc0VUcUdkODVR?= =?utf-8?B?WThPZ0tMUElQK1h2dk9SOUQzdEVxRGxrdjhqa0JrRGlkRWtMQ0lPNDZvRmJL?= =?utf-8?B?ZVhqbmxRYUVSbWJndlBvcXY5czNzTG1oRUY2MFdzRnRwaEplOURxRUdPbGRp?= =?utf-8?B?V08vMVN3OVpoTzBPMHNJSTRHZGgrc3FFWUNnQXpPWnZ1VFlyUXp1Ym1sVzFh?= =?utf-8?B?UkxEWUdZZTNwNHJ5WU9aeHdDcW1yV1VGNGxjRG1IUVpNMzVsVkI4WHpOaDlp?= =?utf-8?B?dFpzd3d0ZXFWU0NqbjlHTDF1MTk4RzJqL1NBY3l6Qzl5dDFONVloNkx0R3Jp?= =?utf-8?B?aVBjbzljWkNJZkYvMUM1aW9kVTZOd3grVm81all4Sml5N1dseWdia3dkT3hh?= =?utf-8?B?aTB3YlVPN25ndHVFcHZ4aFNVa2Z1cEhYU1JNeDgxeFVjR1FGMTlvWml4Tjlj?= =?utf-8?B?QzhPRVQvNW1aK01PTnowZWpqaFBLWjlVQUw2elhNWkthWWU3N3gxN3d4QjFL?= =?utf-8?B?WnR1SStIY2xnYlA5a094MEEyeDlJRmJINlZOWEFyRHRFdkpOSVMrSG1qUmM2?= =?utf-8?B?U3NSa1huVktXT1JVSWdjNWo3d3NqQVduT0xjTlplNitIa013bTBKK1QvYnow?= =?utf-8?B?azZCc1FZSXVyWDEwWVNWWU8zelFLWjJJTitGVHJId29vZWtFeWw5T2hnRUJx?= =?utf-8?B?OEhtT1hmQnJaWHY4TFRQcTQvVXNyNnlHN1R5SFdQcjA5b3U0ZVRkR1BoY1Q3?= =?utf-8?B?d0FPUW9ZeVpkN08vb2hlVXptbnorYkpJRkt4TldPWW8vVUxPM2pVZVl6S1Rz?= =?utf-8?B?dUhWL1dIVGtFU05ETzJsdGs4SGFLTjlhTWUzRUROM2F0SzR4N29kZEFYaHM0?= =?utf-8?B?cWNjbFdpVTVWWnlwSjQvaFViVTRiRy9oRWwvL3dmbGV3UWlYZUtJSGkxajQy?= =?utf-8?B?U2xxM3l3Nm1YbDJNL2N1OUhic0tqVUlIWkJYdmo1b0t5cjdRdXBUWTNRd3R1?= =?utf-8?B?WXRyZzhaT21NVWNLc1BWTThHWVpHVWhkYjdPM0VyZS80WjJadlBCY1J1cW42?= =?utf-8?B?aUFVUkswKzI0MzQ4VDBqV1FaRUQyTnVCNG1jN3Vrc0s3QUdaY2lzVDRNbER3?= =?utf-8?B?anc1T0dxRXBTKzF6ZE9DR3p5L0pjc0gxaHVkNUpQaTVzYlFKRTZQTDJHQm9P?= =?utf-8?B?UEVZMWcyU3lua1NEQStNdUVFRGZobFh2Ui9nZ0VNTmVwUzhPTmNsb1JxSE9q?= =?utf-8?B?ZkVCcy9vSzIvUnh2L2JlUmZ5ZW5FZWFRZ2xqdUlSQU1IVUpjMzNqQVhqdEF0?= =?utf-8?B?c2pvcUh2RmZaYTRibExrUGFqeVZ1SVlUL0ZEbE9aYmlXOWNOYTRUdWlxK3Uw?= =?utf-8?B?TE93NVJGYlBlbjllSDRmbytkSDZ1WW5pNlFUTXc2N3VoSGY4NlE2TTNGTzRa?= =?utf-8?B?TllqUy9lREJ6dDJSbWxXWFZSOHZ2RGpMMWs5M0ZZNDljSmRWZlZaRU9yUExK?= =?utf-8?B?M1AvMURYZ2pIK1UzNnBZSWtWOXFTMFBoRDBYc0N3VmcvbVQ3bTVYS3lXdnlH?= =?utf-8?B?US9pdVdkVkJiaVQ2d1ljOVE4RTNGWkZDdmU0VmxhTlRrZUJoUzZIRXlvT3lD?= =?utf-8?B?SllMUlZZYithOUpEWFQ0REpxRlVkeXNrMVh6MFQwajM1NHJZVnJrTmIwejlW?= =?utf-8?B?WGtPRjJ1QURISGhVNkV2SEJuaTNlNEdXMmV5MnVERTFJei9uWm5hWVBJRVBW?= =?utf-8?B?S1VtOUN4U1JyWXN2MjlvRUxBaWIzSEM0UGRHRkMxZ1MrbDdVOGNYSTBWUFBX?= =?utf-8?B?RTNmNy82b05Za0RUTXVaYkx2OHRobC90UGZVcjZGNlJIVHdLMzFubHpSTm8y?= =?utf-8?B?OEpGR3ErYTJFWmpzYkZ4KzBwbHpFakpFTWk2dzhzNERQUXBvNUVYTDJ3b3I4?= =?utf-8?B?c3U3Z2lWSSs1TUl6MlBHQTg1RFJQL082RWRRM2tkZ284S1dYZUdISFYraTBC?= =?utf-8?B?UUpUY2JTdXhWbnozaFlNbE5VcTd2N3EwMkRhWG1raTR0NnZBRnk1MlI1MFdB?= =?utf-8?B?amVNNTZ3bWhPaUFvTWJlMDdnZ0x3MVg0clk3cklmMTBBT2dmM05Ldmp5MjF1?= =?utf-8?B?YUxubEhHUFV4VmQwUmp6R1RNdFg4a1g4bGhPVGVLS09WdEpybngxQ0tXRDNk?= =?utf-8?B?bHo3MG5tSVNaK0wzRVdsK1FwWS9FenpUVUkwL1J3cDVmUS9IbzZhYzVmck8x?= =?utf-8?B?L3loTk52L0xHN0tsTVQ4aml5V3d4MnduaVhqaVRtSC9FUmhzOHpoN1JQUGhR?= =?utf-8?Q?yOIW38IKyEwm/0r4=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1bc07891-90cb-4122-dc4f-08da2783ee1c X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5093.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2022 12:54:42.0257 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Qbzg/HQBs/DE+laXo8UMcYWJxfgDcuvk0jy3YXsdA2WapBOlW+s4iJ0j33wgaGmDnDDLlIruHcegFuT9TVwXcIGRdWxGDQzXfGDRQQ039OI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1362 X-OriginatorOrg: intel.com 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 On 21-Apr-22 2:18 PM, Burakov, Anatoly wrote: > On 21-Apr-22 10:37 AM, David Marchand wrote: >> On Wed, Apr 20, 2022 at 4:47 PM Burakov, Anatoly >> wrote: >>> >>> On 15-Apr-22 6:31 PM, David Marchand wrote: >>>> When releasing some memory, the allocator can choose to return some >>>> pages to the OS. At the same time, this memory was poisoned in ASAn >>>> shadow. Doing the latter made it impossible to remap this same page >>>> later. >>>> On the other hand, without this poison, the OS would pagefault in any >>>> case for this page. >>>> >>>> Remove the poisoning for unmapped pages. >>>> >>>> Bugzilla ID: 994 >>>> Fixes: 6cc51b1293ce ("mem: instrument allocator for ASan") >>>> Cc: stable@dpdk.org >>>> >>>> Signed-off-by: David Marchand >>>> --- >>>>    lib/eal/common/malloc_elem.h |  4 ++++ >>>>    lib/eal/common/malloc_heap.c | 12 +++++++++++- >>>>    2 files changed, 15 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/lib/eal/common/malloc_elem.h >>>> b/lib/eal/common/malloc_elem.h >>>> index 228f178418..b859003722 100644 >>>> --- a/lib/eal/common/malloc_elem.h >>>> +++ b/lib/eal/common/malloc_elem.h >>>> @@ -272,6 +272,10 @@ old_malloc_size(struct malloc_elem *elem) >>>> >>>>    #else /* !RTE_MALLOC_ASAN */ >>>> >>>> +static inline void >>>> +asan_set_zone(void *ptr __rte_unused, size_t len __rte_unused, >>>> +     uint32_t val __rte_unused) { } >>>> + >>>>    static inline void >>>>    asan_set_freezone(void *ptr __rte_unused, size_t size >>>> __rte_unused) { } >>>> >>>> diff --git a/lib/eal/common/malloc_heap.c >>>> b/lib/eal/common/malloc_heap.c >>>> index 6c572b6f2c..5913d9f862 100644 >>>> --- a/lib/eal/common/malloc_heap.c >>>> +++ b/lib/eal/common/malloc_heap.c >>>> @@ -860,6 +860,7 @@ malloc_heap_free(struct malloc_elem *elem) >>>>        size_t len, aligned_len, page_sz; >>>>        struct rte_memseg_list *msl; >>>>        unsigned int i, n_segs, before_space, after_space; >>>> +     bool unmapped_pages = false; >>>>        int ret; >>>>        const struct internal_config *internal_conf = >>>>                eal_get_internal_configuration(); >>>> @@ -999,6 +1000,13 @@ malloc_heap_free(struct malloc_elem *elem) >>>> >>>>                /* don't care if any of this fails */ >>>>                malloc_heap_free_pages(aligned_start, aligned_len); >>>> +             /* >>>> +              * Clear any poisoning in ASan for the associated >>>> pages so that >>>> +              * next time EAL maps those pages, the allocator can >>>> access >>>> +              * them. >>>> +              */ >>>> +             asan_set_zone(aligned_start, aligned_len, 0x00); >>>> +             unmapped_pages = true; >>>> >>>>                request_sync(); >>>>        } else { >>>> @@ -1032,7 +1040,9 @@ malloc_heap_free(struct malloc_elem *elem) >>>> >>>>        rte_mcfg_mem_write_unlock(); >>>>    free_unlock: >>>> -     asan_set_freezone(asan_ptr, asan_data_len); >>>> +     /* Poison memory range if belonging to some still mapped >>>> pages. */ >>>> +     if (!unmapped_pages) >>>> +             asan_set_freezone(asan_ptr, asan_data_len); >>>> >>>>        rte_spinlock_unlock(&(heap->lock)); >>>>        return ret; >>> >>> I suspect the patch should be a little more complicated than that. When >>> we unmap pages, we don't necessarily unmap the entire malloc element, it >>> could be that we have a freed allocation like so: >>> >>> | malloc header | free space | unmapped space | free space | next malloc >>> header | >>> >>> So, i think the freezone should be set from asan_ptr till aligned_start, >>> and then from (aligned_start + aligned_len) till (asan_ptr + >>> asan_data_len). Does that make sense? >> >> (btw, I get a bounce for Zhihong mail address, is he not working at >> Intel anymore?) >> >> To be honest, I don't understand if we can get to this situation :-) >> (especially the free space after the unmapped region). >> But I guess you mean something like (on top of current patch): >> >> @@ -1040,9 +1040,25 @@ malloc_heap_free(struct malloc_elem *elem) >> >>          rte_mcfg_mem_write_unlock(); >>   free_unlock: >> -       /* Poison memory range if belonging to some still mapped >> pages. */ >> -       if (!unmapped_pages) >> +       if (!unmapped_pages) { >>                  asan_set_freezone(asan_ptr, asan_data_len); >> +       } else { >> +               /* >> +                * We may be in a situation where we unmapped pages >> like this: >> +                * malloc header | free space | unmapped space | free >> space | malloc header >> +                */ >> +               void *free1_start = asan_ptr; >> +               void *free1_end = aligned_start; >> +               void *free2_start = RTE_PTR_ADD(aligned_start, >> aligned_len); >> +               void *free2_end = RTE_PTR_ADD(asan_ptr, asan_data_len); >> + >> +               if (free1_start < free1_end) >> +                       asan_set_freezone(free1_start, >> +                               RTE_PTR_DIFF(free1_end, free1_start)); >> +               if (free2_start < free2_end) >> +                       asan_set_freezone(free2_start, >> +                               RTE_PTR_DIFF(free2_end, free2_start)); >> +       } >> >>          rte_spinlock_unlock(&(heap->lock)); >>          return ret; >> > > Something like that, yes. I will have to think through this a bit more, > especially in light of your func_reentrancy splat :) > So, the reason splat in func_reentrancy test happens is as follows: the above patch is sorta correct (i have a different one but does the same thing), but incomplete. What happens then is when we add new memory, we are integrating it into our existing malloc heap, which triggers `malloc_elem_join_adjacent_free()` which will trigger a write into old header space being merged, which may be marked as "freed". So, again we are hit with our internal allocator messing with ASan. To properly fix this is to answer the following question: what is the goal of having ASan support in DPDK? Is it there to catch bugs *in the allocator*, or can we just trust that our allocator code is correct, and only concern ourselves with user-allocated areas of the code? Because it seems like the best way to address this issue would be to just avoid triggering ASan checks for certain allocator-internal actions: this way, we don't need to care what allocator itself does, just what user code does. As in, IIRC there was a compiler attribute that disables ASan checks for a specific function: perhaps we could just wrap certain access in that and be done with it? What do you think? -- Thanks, Anatoly