From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 91214A04DB; Thu, 15 Oct 2020 20:01:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CCECA1DDD7; Thu, 15 Oct 2020 20:01:15 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 71DDE1DDD7 for ; Thu, 15 Oct 2020 20:01:14 +0200 (CEST) IronPort-SDR: I4w44LRfr96ZKkPR0kpA26YV0jzaX4sJiSSnanrRuDSHWV4m3gO7cFMiI8m3Q4c+WTdF8eUGhx 7srT1MFfkC9Q== X-IronPort-AV: E=McAfee;i="6000,8403,9775"; a="162951017" X-IronPort-AV: E=Sophos;i="5.77,379,1596524400"; d="scan'208";a="162951017" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 11:01:12 -0700 IronPort-SDR: h7CTyc8dwA2jBOnBUFTR51NpuAgHEBAZ0cyIWEYAl9Fy7fl/CrBClJkzjKnjDWaemAPuHvA3cc gnu0fAWLhxQA== X-IronPort-AV: E=Sophos;i="5.77,379,1596524400"; d="scan'208";a="521933019" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.243.220]) ([10.213.243.220]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 11:01:11 -0700 To: "Mohakud, Amiya Ranjan" , dpdk-dev Cc: "Dey, Souvik" References: <9fbe81bd-1feb-db15-4b37-7bc51483b82c@intel.com> From: "Burakov, Anatoly" Message-ID: <58888db2-a3c5-befc-6886-d510c7fd6646@intel.com> Date: Thu, 15 Oct 2020 19:01:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] eal: DPDK: 18.11.6 version rte_eal_init() function cleans the runtime directory in 5.4.35 kernel 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 15-Oct-20 5:14 PM, Mohakud, Amiya Ranjan wrote: > + Souvik > > *From:*Mohakud, Amiya Ranjan > *Sent:* 15 October 2020 21:38 > *To:* Burakov, Anatoly ; dpdk-dev > *Subject:* RE: [dpdk-dev] eal: DPDK: 18.11.6 version rte_eal_init() > function cleans the runtime directory in 5.4.35 kernel > > Hi Anatoly - Thanks for helping on this. > > I am not aware, where the primary process re-creates the files. Can you > please point me to that? As per my code browsing and understanding, I > can see, fbarray_memzone file gets created in > rte_eal_memzone_init()->rte_fbarray_init() and it stays there till > eal_clean_runtime_dir() gets called towards end of rte_eal_init(). This > does not get deleted in 4.19 kernel, but in 5.4, it does. > > /I'm not sure i understand. Primary process is supposed to clear the > files. It will then recreate them. Are you suggesting that it's clearing > them *after* it has created them?/ > > / > /Going by my observation, the file highlighted below gets deleted by the > time rte_eal_init() is over. > > srwxr-xr-x 1 root root      0 Oct 15 11:24 mp_socket > > -rw------- 1 root root  12432 Oct 15 11:24 hugepage_info > > -rw------- 1 root root 188416 Oct 15 11:24 fbarray_memzone > > -rw------- 1 root root 397312 Oct 15 11:24 fbarray_memseg-2048k-0-1 > > -rw------- 1 root root 397312 Oct 15 11:24 fbarray_memseg-2048k-0-0 > > -rw------- 1 root root 397312 Oct 15 11:24 fbarray_memseg-2048k-0-3 > > -rw------- 1 root root 397312 Oct 15 11:24 fbarray_memseg-2048k-0-2 > > -rw------- 1 root root  16529 Oct 15 11:24 config > > Please reach out to me for further clarification. > > Regards > > Amiya Hi, Sorry, yes, you're right (it's been a while since i looked at the code), it removes unused stuff at the end of init. There's even a comment explaining why that's done :D It sounds like closing the file descriptor also drops the lock. This locking business is a huge pain because we have to support old kernels which don't have the only sane file locking implementation that Linux has. While i wouldn't go as far as to say "this is a kernel regression" as most likely it's me who's at fault here, but this definitely shouldn't happen. Unfortunately, i won't be online for the next two weeks, but i'll definitely look into this after i'm back, so thanks for your report. -- Thanks, Anatoly