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 0BCEFA0553; Sat, 11 Jun 2022 18:25:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD2D94021E; Sat, 11 Jun 2022 18:25:47 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id AEE5340150; Sat, 11 Jun 2022 18:25:46 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1989C39AE; Sat, 11 Jun 2022 18:25:44 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 17D953A1F; Sat, 11 Jun 2022 18:25:44 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -2.6 Received: from [192.168.1.59] (unknown [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 09E79375E; Sat, 11 Jun 2022 18:25:39 +0200 (CEST) Message-ID: Date: Sat, 11 Jun 2022 18:25:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [Bug 1030] rte_malloc() and rte_free() get stuck when used with signal handler Content-Language: en-US To: Sarosh Arif , bugzilla@dpdk.org Cc: dev , Stephen Hemminger References: <20220609082553.3b875228@hermes.local> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2022-06-10 08:04, Sarosh Arif wrote: > On Thu, Jun 9, 2022 at 8:26 PM Stephen Hemminger > wrote: >> >> On Thu, 09 Jun 2022 12:47:43 +0000 >> bugzilla@dpdk.org wrote: >> >>> https://bugs.dpdk.org/show_bug.cgi?id=1030 >>> >>> Bug ID: 1030 >>> Summary: rte_malloc() and rte_free() get stuck when used 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 >>> --> https://bugs.dpdk.org/attachment.cgi?id=205&action=edit >>> calls rte_malloc and rte_free in the handler and main code >>> >>> I have a dpdk based application which uses rte_malloc() and rte_free() >>> frequently in it's main code. The general method to close the application 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 stuck 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 lock is placed >>> and the application receives SIGINT, it goes into the handler without 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 stuck >>> >> >> rte_malloc and rte_free are not async sigsafe() >> > Oh, I did not know that. This should be mentioned in the documentation. Is there anything except that is/should be async-signal-safe? >> but then again regular glibc is not either. > 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? 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.