From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3B26EBC0053; Mon, 30 Apr 2018 13:08:06 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 30 Apr 2018 14:08:02 +0100 To: Anatoly Burakov , References: <00fe124e2057fe6c5596fb0a24bdcce9b36c3b90.1525082912.git.anatoly.burakov@intel.com> From: Andrew Rybchenko Message-ID: <8d3e2cc3-d4fd-6c84-e136-aef593b5ea4d@solarflare.com> Date: Mon, 30 Apr 2018 16:07:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <00fe124e2057fe6c5596fb0a24bdcce9b36c3b90.1525082912.git.anatoly.burakov@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23814.003 X-TM-AS-Result: No--5.697000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1525093687-5DL+zukEroMY Subject: Re: [dpdk-dev] [PATCH] eal: check if hugedir write lock is already being held X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 13:08:08 -0000 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