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 B78FFA0543; Mon, 13 Jun 2022 11:49:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 990B640150; Mon, 13 Jun 2022 11:49:23 +0200 (CEST) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by mails.dpdk.org (Postfix) with ESMTP id 5D02A400EF for ; Mon, 13 Jun 2022 11:49:22 +0200 (CEST) Received: by mail-ot1-f48.google.com with SMTP id c3-20020a9d6843000000b0060c2c63c337so4028115oto.5 for ; Mon, 13 Jun 2022 02:49:22 -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:content-transfer-encoding; bh=CPF6B+BYTang2uCBtIM5BZh8YkjfKwb7rcIR5EICg2g=; b=nSWb3dbkUWUPqO0vrMpS4at666HqQVIlILKMNONzpZHPslO5dI2Yu/n19PV4fEgIcG ua/f2KnxzgwXWdozZcHq0p5/GzUpgPZw64PB/kJa7NqR5HbBrMJzeoA8EUwvfpF+e0Nx onNH2XX1qQaqyeQ30gmpC/EvkoCXBmyRctvUxwpUi3hKrqAXXT16hD3JxV4Hf3IUJF0V Ljz+VHuiR86kvHMij6wcyUL+3Hd/M162DowVEDgcCuNgwu+F8IQXGvxblTAX5TjVNYT9 Kyjw3PhOpjxER2YsFxEnYSbdLJVlfNOopjfA3plNhchDkYba1VA9KP+nNIOffDzeAIxL RL+g== 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:content-transfer-encoding; bh=CPF6B+BYTang2uCBtIM5BZh8YkjfKwb7rcIR5EICg2g=; b=0I/6xZScycUJs6rbMIngTppDgVqx19fuhYnNx5oFS7W8jomNm1Ev4tEZgcvkZOkgNZ O5W68RhNoBwRZRfnGlrAWUMvqokfLaHToj8VsiG9Mfv41rMRb5zt4BArZUjb6UaL+4R0 mQ2N1TsZY8jE9v4Z7Du0zmgsi47jJ5w2GMT6kxgFyILYILkPSHZ63GMoT4UZMKhK7FjT Qou/ZkINVaF1O45pJlhHXPepJT6bZuyC5tvMa9RJ/7CAx396nFSG8p43z0d0cQnSgC72 I21HBAN0h3eeVx0c/aNxBegZRINNsTc8qcSM1fhOmTBS1y/jEqhgpAcfZ9YhE2+QFZF2 zAqg== X-Gm-Message-State: AOAM533Rw6HqxCAqKz66ozi+S01CwM0qGPiKgASuorjQA65IzZAyY8UJ Xcm3ushBkXeSXRVaGOHTPxcJu5b8dB6m8vefsS60rVkrAXo= X-Google-Smtp-Source: ABdhPJzvDoc4qkWPlZRz7ShWd+YXzTCl7CK+CiaoaFmUpGGTjf+pWfCtrhesiGI17pqSM+k5CTGCju7cOdUx/Pc8VwY= X-Received: by 2002:a05:6830:1be8:b0:60c:1e7:52d7 with SMTP id k8-20020a0568301be800b0060c01e752d7mr14827377otb.126.1655113761612; Mon, 13 Jun 2022 02:49:21 -0700 (PDT) MIME-Version: 1.0 References: <20220609082553.3b875228@hermes.local> In-Reply-To: From: Sarosh Arif Date: Mon, 13 Jun 2022 14:48:45 +0500 Message-ID: Subject: Re: [Bug 1030] rte_malloc() and rte_free() get stuck when used with signal handler To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: bugzilla@dpdk.org, dev , Stephen Hemminger 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 Thank you for help, I'll do it this way. On Sat, Jun 11, 2022 at 9:25 PM Mattias R=C3=B6nnblom wrote: > > 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=3D1030 > >>> > >>> 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=3D205&action=3Dedit > >>> 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 applica= tion is > >>> though sending SIGINT. The application has a signal handler written f= or cleanup > >>> purposes before closing the application. The handler also uses rte_fr= ee() 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 ac= quire 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-sa= fe? > > >> 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.