From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Rybchenko Subject: Re: [PATCH] eal: check if hugedir write lock is already being held Date: Mon, 30 Apr 2018 16:07:58 +0300 Message-ID: <8d3e2cc3-d4fd-6c84-e136-aef593b5ea4d@solarflare.com> References: <00fe124e2057fe6c5596fb0a24bdcce9b36c3b90.1525082912.git.anatoly.burakov@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit To: Anatoly Burakov , Return-path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id F3FD0DD2 for ; Mon, 30 Apr 2018 15:08:07 +0200 (CEST) In-Reply-To: <00fe124e2057fe6c5596fb0a24bdcce9b36c3b90.1525082912.git.anatoly.burakov@intel.com> Content-Language: en-GB List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 04/30/2018 01:38 PM, Anatoly Burakov wrote: > At hugepage info initialization, EAL takes out a write lock on > hugetlbfs directories, and drops it after the memory init is > finished. However, in non-legacy mode, if "-m" or "--socket-mem" > switches are passed, this leads to a deadlock because EAL tries > to allocate pages (and thus take out a write lock on hugedir) > while still holding a separate hugedir write lock in EAL. > > Fix it by checking if write lock in hugepage info is active, and > not trying to lock the directory if the hugedir fd is valid. > > Fixes: 1a7dc2252f28 ("mem: revert to using flock and add per-segment lockfiles") > Cc: anatoly.burakov@intel.com > > Signed-off-by: Anatoly Burakov Tested-by: Andrew Rybchenko