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 548B5A0557; Fri, 10 Jun 2022 08:05:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 160CD40689; Fri, 10 Jun 2022 08:05:06 +0200 (CEST) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by mails.dpdk.org (Postfix) with ESMTP id 2D8A740221 for ; Fri, 10 Jun 2022 08:05:04 +0200 (CEST) Received: by mail-ot1-f50.google.com with SMTP id c3-20020a9d6843000000b0060c2c63c337so1853025oto.5 for ; Thu, 09 Jun 2022 23:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emumba-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PSKqXwuToySOi7T2gSMSbPqlrU/kO34h44u4G3qc6rA=; b=nmjDk7aMtR+O5HMJF2AMVisDR4ylLqGOtgSBkZq/vN8QPCBL1OxunMDKswC7Jci5up QyQ81p7RIdEmelXo15bBlkBHBXY7JEV1H/GAsEMaTuinPoDHB5Fb7lQ+nyaS9gzN/v44 OxfcNAUyG7mcuGhE8b6mtaz27Udmxw8Pgv2SVNWHQaTu7LCGdyR1SvAyeKnKFIMpU0ji rEJqkJj3VJ/7HaKCfZCamyZyIhWbfYfofNCVYRoaUDYoYVVcGz3tD/idLitU8wapkdRS RFcktbea6xbupe9aYrMiMXQCfOHG92j6aftmr2CV05RufQIhqW+E8JAJPsgIJ5W9HjZ4 wUHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PSKqXwuToySOi7T2gSMSbPqlrU/kO34h44u4G3qc6rA=; b=OldKJZDO5bdAJM2PvMUcQ3W9luGsUKADVOUkivbVO3aHA+u5Z/woE+gjoWk7DrlvfB 6JDNGkZ9n08bH47i7H93P22GYISw81k+vw8CRvQ3L9K6Rzu9swdsGlUDDbTAL9Qbp4J3 c4ZrYdVaYyL+sDQZ8IU/c2xzIy1k+4itbnZw9WSOpe8cE8PoN0To+C721yLTceqDAlGG uoDjzqifYqrmBVLKrP+xdMzZBgdV1A81Uf2ulYkTSCsuW4fwXm9/1LetQr+rNjw5O9xM LhvV25g28p6jDZyytAMWtBtdxkIdRZLtQ3/XEh09ZSHGl5VDmK7WOx8Vl0cxvgE+10tm RuBw== X-Gm-Message-State: AOAM533IC+dOru3Ur3neefJUPuydo8fbcmHIMnDFKp5Ifpqx+IuDdA0r DwBXFyWxV/a93PSacc/pV1v/tybftIlXGiJ6c5V47A== X-Google-Smtp-Source: ABdhPJzOs7IO7JiXXbetjG5NOWXWsRHmLlm1FGfi4Ue0PEs73ESg07u+m+hNL/E3YgsxcFMqbf0366GOgyHtg0n8kjM= X-Received: by 2002:a9d:4007:0:b0:60c:1cee:a93a with SMTP id m7-20020a9d4007000000b0060c1ceea93amr4596762ote.310.1654841103350; Thu, 09 Jun 2022 23:05:03 -0700 (PDT) MIME-Version: 1.0 References: <20220609082553.3b875228@hermes.local> In-Reply-To: <20220609082553.3b875228@hermes.local> From: Sarosh Arif Date: Fri, 10 Jun 2022 11:04:27 +0500 Message-ID: Subject: Re: [Bug 1030] rte_malloc() and rte_free() get stuck when used with signal handler To: bugzilla@dpdk.org Cc: dev , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" 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 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. > 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?