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 A6E92426B7; Wed, 4 Oct 2023 16:51:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 671F6402A9; Wed, 4 Oct 2023 16:51:41 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id B53E14027C for ; Wed, 4 Oct 2023 16:51:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696431099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HoEedZZXsA3BzGX16uLFTFlKgOnN+gOzOpp32ccEJnM=; b=HswOxGxIpFyCxyELXmiSPAwx+EdPL7NBpsleABaYCShDFh9+zAOc5dWZhzw3GQ5XD0HVut tRePKcapW/7fm7J8XRuvJcOf1GeAheXtKriXmEvd/TGNwRlYTdbAFpOWKpQbSHO/IaV2+z HyY8LiiA+MTx24Zdta0iCdlpNTz7lak= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-556-XiqVtWfVOWyN1_8KmJwvkQ-1; Wed, 04 Oct 2023 10:51:38 -0400 X-MC-Unique: XiqVtWfVOWyN1_8KmJwvkQ-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2bfeaf8cc4bso20023221fa.0 for ; Wed, 04 Oct 2023 07:51:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696431096; x=1697035896; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HoEedZZXsA3BzGX16uLFTFlKgOnN+gOzOpp32ccEJnM=; b=HmNSCguraAAGbQ/H1P7Ue5uRq1IOYXtpOOOiOc/2jB/e/yTF4Opi+hl2be6FkEdS0x 46SIo7bsWohAlnpf5qrk9SBQzgvw2+4HLRMh62c5xO86ivKrJFzMr2VPXTbXHJhZdWs9 Yx6bPY2i/KS8bBjR/rvvBoOLfdWjZgzTr96k01G8VlyCg12d3wkZgvAnZDAMADnE3r+r bW7P+QzygmYSEpuXizfvI32ZWF8e2u4taqPaHHJO+8DkzwF+wY2O7rOCGNjWIi2U949u 1hBUl/Q0WkQblAatEkegmJNCps/HOq1mIBZ+yb+31Zl8r0Hs3Cwom6t4HZJeFf3ujo5d rEqg== X-Gm-Message-State: AOJu0YxzVxQvC5cQtkhnBAA4fVNEVOCJDul5eUdotpoM4EJFu+pQGRQ+ ko2ntxwc7SQNRjE+tTuZO7WB1SPehQHHm+DiNc0zp2Z1qE5vA0GD9RcXFjuXy/Z5VkwwqsB3x9/ gQ27021K2u5UeHLWFKos= X-Received: by 2002:a2e:8e8c:0:b0:2c1:7fcf:c974 with SMTP id z12-20020a2e8e8c000000b002c17fcfc974mr2242089ljk.23.1696431096622; Wed, 04 Oct 2023 07:51:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IED9kNQb8IRjXYrZrTbnwUgTmD092eF5mNv34MVtsh86vTrTRaOlcgsKIGuswKcv6vVgeCyf+gCDOfPXhq1IVI= X-Received: by 2002:a2e:8e8c:0:b0:2c1:7fcf:c974 with SMTP id z12-20020a2e8e8c000000b002c17fcfc974mr2242083ljk.23.1696431096325; Wed, 04 Oct 2023 07:51:36 -0700 (PDT) MIME-Version: 1.0 References: <20231004142308.15395-1-artur.paszkiewicz@intel.com> In-Reply-To: <20231004142308.15395-1-artur.paszkiewicz@intel.com> From: David Marchand Date: Wed, 4 Oct 2023 16:51:25 +0200 Message-ID: Subject: Re: [PATCH] mem: allow using ASan in multi-process mode To: Artur Paszkiewicz , anatoly.burakov@intel.com Cc: dev@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Oct 4, 2023 at 4:23=E2=80=AFPM Artur Paszkiewicz wrote: > > Multi-process applications operate on shared hugepage memory but each > process has its own ASan shadow region which is not synchronized with > the other processes. This causes issues when different processes try to > use the same memory because they have their own view of which addresses > are valid. > > Fix it by mapping the shadow regions for memseg lists as shared memory. > The primary process is responsible for creating and removing the shared > memory objects. > > Disable ASan instrumentation for triggering the page fault in > alloc_seg() because if the segment is already allocated by another > process and is marked as free in the shadow, accessing this address will > cause an ASan error. > > Signed-off-by: Artur Paszkiewicz Interesting patch. I have a few questions: - did you test with --in-memory mode? with --no-huge? - I did not look at the patch, but I wonder if there is a risk some "local" ASan region (for the process heap, for example) can overlap with some "shared" ASan region (for shared DPDK hugepages). - with this work, would unit tests (that were marked failing with ASan) be ok now? See REGISTER_FAST_TEST macro in app/test. Thanks for working on this topic. --=20 David Marchand