[dpdk-dev] [PATCH 09/14] eal: close mem config on cleanup

Burakov, Anatoly anatoly.burakov at intel.com
Tue Apr 28 11:20:27 CEST 2020


On 27-Apr-20 6:00 PM, Stephen Hemminger wrote:
> On Mon, 27 Apr 2020 13:12:32 +0100
> "Burakov, Anatoly" <anatoly.burakov at intel.com> wrote:
> 
>> On 04-Jan-20 1:33 AM, Stephen Hemminger wrote:
>>> Resolves file descriptor left open after rte_eal_cleanup.
>>>
>>> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
>>> ---
>>>    lib/librte_eal/linux/eal/eal.c | 6 ++++++
>>>    1 file changed, 6 insertions(+)
>>>
>>> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
>>> index 9ad81378f23c..e5c2a24322e9 100644
>>> --- a/lib/librte_eal/linux/eal/eal.c
>>> +++ b/lib/librte_eal/linux/eal/eal.c
>>> @@ -1346,6 +1346,12 @@ rte_eal_cleanup(void)
>>>    	rte_mp_channel_cleanup();
>>>    	eal_cleanup_config(&internal_config);
>>>    	rte_eal_log_cleanup();
>>> +
>>> +	if (mem_cfg_fd != -1) {
>>> +		close(mem_cfg_fd);
>>> +		mem_cfg_fd = -1;
>>> +	}
>>> +
>>>    	return 0;
>>>    }
>>>    
>>>    
>>
>> For the patch,
>>
>> Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>
>>
>> However i think it's incomplete, as there are also memory-backing
>> fbarrays that are still mapped. Also, secondary processes have their own
>> shadow copies of the master page table located in the mem config, so
>> those should be destroyed on cleanup too.
>>
> 
> This patch set was targeting things in stages. It is not complete, some of the
> cleanups would be hard to do. Just getting the obvious things first.
> 

Fair enough. You still got my ack :)

-- 
Thanks,
Anatoly


More information about the dev mailing list