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 3371C41FD3 for ; Wed, 30 Aug 2023 21:13:31 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 324DE40284; Wed, 30 Aug 2023 21:13:31 +0200 (CEST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by mails.dpdk.org (Postfix) with ESMTP id 85F6B4027C; Wed, 30 Aug 2023 21:13:29 +0200 (CEST) Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2bcb54226e7so15005541fa.1; Wed, 30 Aug 2023 12:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693422809; x=1694027609; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=D8I/Qivzfj0CR2yOTba9DD8Ocu5M7w95y8M07VDo09o=; b=EF3h5C5XuwNRTxVegWOnPFj7o7VFyF5tRtwdjhY3nSd5uHUunC5/sei/aRulvbTxFw I7Bb3uDRFoPqboGyyxDWXuLtYPl/VfgqV/L2NAq4UqHBLaxtJ2CRp5jDocafZaO5HKhv 7TbKxsYUlIWsMP5e+zb6dqZbTFcFJckr84ZX1X2mw4kRf+sug/lBTXucsjY4SDAxuwOV QNDPRViJ6PKDfzUhgKs6kiYQOXA802m9dwM7leaLDtvHNKObtMqixusQHMYEHkEE+fqA i3NM/tuZE7IPuS0K08y6aHJaYA6jUvaoIaycRwJ1cq/5i3HJLn8AAzT00oVQwDOhi3mI PkQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693422809; x=1694027609; 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:message-id:reply-to; bh=D8I/Qivzfj0CR2yOTba9DD8Ocu5M7w95y8M07VDo09o=; b=RxuI0Mju+bFSkxggYgUnBWJDHOmKtzLPBsjtAAWytE40OOklmPlppl9tH6Vae+OL1m GmnxfcqI3ULhQGgcnKlrtQj6bmSooFwKsbKvKzo/aTdoO7jxWmur6Ark2A8h+AU2BTl2 64fFz2FEAgC12dBVIuWht1nOtL4XG0F7dUKA8Fe53J03T8Go4aLWnK79W62CCSZ+9qAt PgsAx9Qh4Djq+KvP4dSydgITwcPQ/dRLmtJMbqva/JKCWfZaKrR1yHhA9l9+Y89cD12c SmlH43AOq74d1FHwxLNOh58zUiAFi6I6/2nbXzcCth1a8uxc//7eZ0UKYTkSLJrzaC/W oAQw== X-Gm-Message-State: AOJu0YwpQbIKWICcBOlC+mJlnyq3qQEEf0tN1ZFWk/eUdjnWrZwu2+CT qPh/7o1VXUrLhyTA5kMuo44= X-Google-Smtp-Source: AGHT+IFzxqYvql3b0/vQdzm6j/jPxkadYaTWGMCyu/BGV8AVNBPr/IDT0OZhtBycUjuGqxiRfTTRhA== X-Received: by 2002:a05:651c:1065:b0:2bc:c2d8:e050 with SMTP id y5-20020a05651c106500b002bcc2d8e050mr168954ljm.24.1693422808454; Wed, 30 Aug 2023 12:13:28 -0700 (PDT) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id w8-20020a2e9988000000b002b9f4841913sm2718249lji.1.2023.08.30.12.13.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Aug 2023 12:13:27 -0700 (PDT) Date: Wed, 30 Aug 2023 22:13:26 +0300 From: Dmitry Kozlyuk To: Artemy Kovalyov Cc: , Thomas Monjalon , Ophir Munk , , Anatoly Burakov , "Stephen Hemminger" , Morten =?UTF-8?B?QnLDuHJ1cA==?= Subject: Re: [PATCH] eal: fix memory initialization deadlock Message-ID: <20230830221326.7b9f1289@sovereign> In-Reply-To: <20230830103303.2428995-1-artemyko@nvidia.com> References: <20230830103303.2428995-1-artemyko@nvidia.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org 2023-08-30 13:33 (UTC+0300), Artemy Kovalyov: > Following these changes, the RW-lock no longer supports > recursion, implying that a single thread shouldn't obtain a read lock if > it already possesses one. The problem arises during initialization: the > rte_eal_init() function acquires the memory_hotplug_lock, and later on, > the sequence of calls rte_eal_memory_init() -> eal_memalloc_init() -> > rte_memseg_list_walk() acquires it again without releasing it. This > scenario introduces the risk of a potential deadlock when concurrent > write locks are applied to the same memory_hotplug_lock. To address this > we resolved the issue by replacing rte_memseg_list_walk() with > rte_memseg_list_walk_thread_unsafe(). There is another call to rte_memseg_list_walk() during initialization: from eal_dynmem_hugepage_init(), please address it too.