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 548B1A00BE; Thu, 9 Jun 2022 17:25:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 47F7640689; Thu, 9 Jun 2022 17:25:59 +0200 (CEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mails.dpdk.org (Postfix) with ESMTP id 9030F40220 for ; Thu, 9 Jun 2022 17:25:57 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id 187so21347199pfu.9 for ; Thu, 09 Jun 2022 08:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CKi1LLswF+UGKhbR4GYaSTJR9W5lhz0KS1lvybDtrkQ=; b=h0pfMJVvw6SEz+b8XnQsTb9wj6LKfO56L307P0fWeC2QLmziQtej39Ahycy/yLvhs0 JtyjG1CU2xmMYNvx/bzJu57gpvHmsHYPWfBgNO6J2sxM8F3HkTjkZbUbHUmcDvvf9Ock zCgJhh3YPjRqYSFycicsZOOcz6liB9G9Nmp92zzenmszv0NgnNesoKwK5pmBp/b8gZVA tNcwEMG+tcv1dQf5T+m36d2mKvRld16R5Op2n9WkHTT+sXSppx2u90Rof44RKs/K9w2d LbkG5XIu9piI3ODp6s6De65jdQrDmZLhrQTZJjGnA+2dNOXipDc/LyjBttnNpWgWQA1Q D6fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CKi1LLswF+UGKhbR4GYaSTJR9W5lhz0KS1lvybDtrkQ=; b=qKIvZprMnxE/R/FSefIxeWRMBa235JyPEwPDhjWWO13iKyD2wNh24zjyLrubtBjFTH 18F6hXaLXGM6zRnUv3cARFHxklvNkz+wUSGs9CnXtE2m50wSRQn3jvmHc11hO7G+GOU5 xjF8upPbd6phlae5LuypRxEaVr7a3vBcmpXcrFzg+f1KG9QFDVHcpiWnNPKRl/XguGWZ nMJFaj57asdhXqc3ChK0T+m0QnAqhhG3J+h4VbTeaSN+0y9sJujh6t1SJwnL/7kJN8cY sIAKD+4EOITcK3pu42ALIWHrYdBUU+ewx9RQRfUDOc1YFrI/z0NjHPbOovG1JUVjl/CO /+zw== X-Gm-Message-State: AOAM533NiP6QtFYLm6BQjR2erVskCvk1CxslcB+yMOCnWlFdoJZz2clb /rVvuW+hMC6xChH4yNd4GCJju0cWLhfQmQ== X-Google-Smtp-Source: ABdhPJy5zjGZfnO1HEnNErONdetUmt9CY5GkIkfa60a/9kCYqMpRa+NhRYrgFFi7AVD2O2T5Jawcfw== X-Received: by 2002:a05:6a00:240c:b0:51b:9bfc:90db with SMTP id z12-20020a056a00240c00b0051b9bfc90dbmr41060104pfh.24.1654788356710; Thu, 09 Jun 2022 08:25:56 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id y23-20020a056a00181700b00518c68872b9sm10488378pfa.216.2022.06.09.08.25.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 08:25:56 -0700 (PDT) Date: Thu, 9 Jun 2022 08:25:53 -0700 From: Stephen Hemminger To: bugzilla@dpdk.org Cc: dev@dpdk.org Subject: Re: [Bug 1030] rte_malloc() and rte_free() get stuck when used with signal handler Message-ID: <20220609082553.3b875228@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 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() but then again regular glibc is not either.