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 8088FA0542; Wed, 5 Oct 2022 19:31:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4354240E2D; Wed, 5 Oct 2022 19:31:03 +0200 (CEST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by mails.dpdk.org (Postfix) with ESMTP id E2C6240E5A for ; Wed, 5 Oct 2022 19:31:01 +0200 (CEST) Received: by mail-pl1-f181.google.com with SMTP id h10so13247922plb.2 for ; Wed, 05 Oct 2022 10:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=J1RFoqS0g+zssA9ToXHlZ2AXDvIoTkV9R7JU+0N60HU=; b=JGLMxjO8iQY4K4jjJiOqFg5PmwPM1X7co734ZMdQHoAxQUEKZ+oc4wWfy/dPDWcXha KV9c4VTiP9Xs9WfGeqPYeFlbJffHYOUbsGk1NBQo1o+6NmiWRalsGOERuReirBuSUvmb n3ONSgASiOvGj1KI5cN/oWlhTJi/N9JKiGhBGns025usPWnUcbHkEAAFr4BzrARgUyrp ZrSztl4g72h92suhMaeKC6hL5q8tHe/LxhDX2J11zfNqkVgrJJBj1Ir8PfgYoel2MEgy lVRTL0Lqg0Ph51dPx1zKI8u+ljnpgPM3tNfc3H+++RW4Wl/Su94s9BdSwlC8BqO5V2W+ 8lnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=J1RFoqS0g+zssA9ToXHlZ2AXDvIoTkV9R7JU+0N60HU=; b=CsfHgUwtQhTl3H47g/h7wK6wVz0HM7D6LurmiTB9xyiD0kEeY7k0Mz94f8Th8rhrA9 QlDYKQy3qS2aFpsQugdI7kTCE2/l47exprlWfh97oYARD/hN/+ex9AfeVEB2jFECpYTA DFdUC/TMTgqLZN9twCzocGRf1H+5QusJAW7GpPVytcO7mRDqEZly/ZSk3oIILSh4kQ4Q aoAXtoSI2FdjEfM9C1diPlc94OdRvJe3zqn4slW/kfAmCLIcDJrb7Dlyn4rC/Kh1qUQf 9Atrko8dtkAW+Bpz8v7N41dqda5k6xOZ1ZFhdBGEt6g23yooah0bhXwA/Y+uEfxxscDK OWow== X-Gm-Message-State: ACrzQf0yu/0PuMBDCRwLSQGbMcz/uzBrs8WAiM4ysXE28IxcoAw490w/ elb8u1AoUeHxAKDfOAD3iXBdXg== X-Google-Smtp-Source: AMsMyM4uFwnNPrE+KXqhZ2FL8GoRRUqjBjgp/F2jaNBixt9zAJQyczbJQCUsz4n0vk7V5y8nwVGaEA== X-Received: by 2002:a17:90b:388c:b0:20a:9c33:dd2b with SMTP id mu12-20020a17090b388c00b0020a9c33dd2bmr5992865pjb.225.1664991061032; Wed, 05 Oct 2022 10:31:01 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id c12-20020a17090a4d0c00b0020ad8223f9asm1382427pjg.9.2022.10.05.10.31.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 10:31:00 -0700 (PDT) Date: Wed, 5 Oct 2022 10:30:59 -0700 From: Stephen Hemminger To: Sarosh Arif Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , bugzilla@dpdk.org, dev Subject: Re: [Bug 1030] rte_malloc() and rte_free() get stuck when used with signal handler Message-ID: <20221005103059.112892cd@hermes.local> In-Reply-To: References: <20220609082553.3b875228@hermes.local> MIME-Version: 1.0 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 Mon, 13 Jun 2022 14:48:45 +0500 Sarosh Arif wrote: > Thank you for help, I'll do it this way. >=20 > On Sat, Jun 11, 2022 at 9:25 PM Mattias R=C3=B6nnblom wrote: > > > > On 2022-06-10 08:04, Sarosh Arif wrote: =20 > > > On Thu, Jun 9, 2022 at 8:26 PM Stephen Hemminger > > > wrote: =20 > > >> > > >> On Thu, 09 Jun 2022 12:47:43 +0000 > > >> bugzilla@dpdk.org wrote: > > >> =20 > > >>> https://bugs.dpdk.org/show_bug.cgi?id=3D1030 > > >>> > > >>> Bug ID: 1030 > > >>> Summary: rte_malloc() and rte_free() get stuck when use= d with > > >>> signal handler > > >>> Product: DPDK > > >>> Version: 22.03 > > >>> Hardware: All > > >>> OS: Linux > > >>> Status: UNCONFIRMED > > >>> Severity: normal > > >>> Priority: Normal > > >>> Component: core > > >>> Assignee: dev@dpdk.org > > >>> Reporter: sarosh.arif@emumba.com > > >>> Target Milestone: --- > > >>> > > >>> Created attachment 205 =20 > > >>> --> https://bugs.dpdk.org/attachment.cgi?id=3D205&action=3Dedit = =20 > > >>> calls rte_malloc and rte_free in the handler and main code > > >>> > > >>> I have a dpdk based application which uses rte_malloc() and rte_fre= e() > > >>> frequently in it's main code. The general method to close the appli= cation is > > >>> though sending SIGINT. The application has a signal handler written= for cleanup > > >>> purposes before closing the application. The handler also uses rte_= free() to > > >>> release some of the memory during cleanup. The application gets stu= ck in a > > >>> deadlock. > > >>> > > >>> > > >>> Upon investigation I found out that both rte_free() and rte_malloc(= ) use > > >>> rte_spinlock_lock() function to place a lock on heap. While this lo= ck is placed > > >>> and the application receives SIGINT, it goes into the handler witho= ut releasing > > >>> the lock. Since the handler itself calls rte_free() which tries to = acquire the > > >>> lock it gets stuck. > > >>> > > >>> > > >>> I have attached a sample application to reproduce this problem. > > >>> > > >>> > > >>> Steps to reproduce this problem: > > >>> > > >>> 1. compile the code provided in attachment with any version of dpdk > > >>> 2. run the compiled binary > > >>> 3. press ctrl+c till the prints stop > > >>> > > >>> Actual Results: > > >>> The application gets stuck in either rte_free() or rte_malloc() > > >>> > > >>> Expected Results: > > >>> Application should allocate and free the memory without getting stu= ck > > >>> =20 > > >> > > >> rte_malloc and rte_free are not async sigsafe() > > >> =20 > > > Oh, I did not know that. This should be mentioned in the documentatio= n. =20 > > > > Is there anything except that is/should be async-signal-= safe? > > =20 > > >> but then again regular glibc is not either. =20 > > > Memory allocated with glibc malloc() is freed by itself upon closing > > > the application. My application runs as a secondary process, and it > > > needs to use rte_malloc() specifically because the memory should be > > > shared between the two processes. If I don't free it upon closure it > > > would just be leaked. Is there any other solution for it? =20 > > > > The standard solution is that the signal handler using some appropriate, > > async-signal-safe way talks to the main thread, which then goes on to > > cleanly terminate the application. > > > > A write() to an fd, or an atomic store to a flag are two options. =20 Patch is pending (why is it not merged?) to describe what is signal safe. https://patchwork.dpdk.org/project/dpdk/patch/20220711230448.557715-1-steph= en@networkplumber.org/