linux-kernel - Re: [PATCH V2 1/3] x86/numa_emulation: fix potential memory leak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170626231127.GA53180@WeideMacBook-Pro.local>
Date:   Tue, 27 Jun 2017 07:11:27 +0800
From:   Wei Yang <richard.weiyang@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Wei Yang <richard.weiyang@...il.com>, kirill@...temov.name,
        tglx@...utronix.de, mingo@...hat.com, hpa@...or.com, tj@...nel.org,
        rientjes@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/3] x86/numa_emulation: fix potential memory leak

On Mon, Jun 26, 2017 at 05:31:49PM +0200, Borislav Petkov wrote:
>On Tue, May 02, 2017 at 09:04:51PM +0800, Wei Yang wrote:
>> numa_emulation() needs to allocate a space for phys_dist[] temporarily,
>
>s/a //
>
>> while current code may miss to release this when dfl_phys_nid ==
>> NUMA_NO_NODE.
>
>And when is "dfl_phys_nid == NUMA_NO_NODE"? What does it mean actually?
>

It means numa emulation is not properly configured.

>> It is observed in code review instead of in a real case.
>> This patch fixes this by re-order the code path.
>> 
>> Signed-off-by: Wei Yang <richard.weiyang@...il.com>
>> Acked-by: David Rientjes <rientjes@...gle.com>
>> ---
>>  arch/x86/mm/numa_emulation.c | 36 ++++++++++++++++++------------------
>>  1 file changed, 18 insertions(+), 18 deletions(-)
>> 
>> diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
>> index a8f90ce3dedf..eb017c816de6 100644
>> --- a/arch/x86/mm/numa_emulation.c
>> +++ b/arch/x86/mm/numa_emulation.c
>> @@ -353,6 +353,24 @@ void __init numa_emulation(struct numa_meminfo *numa_meminfo, int numa_dist_cnt)
>>  		goto no_emu;
>>  	}
>>  
>> +	/*
>> +	 * Determine the max emulated nid and the default phys nid to use
>> +	 * for unmapped nodes.
>> +	 */
>> +	max_emu_nid = 0;
>> +	dfl_phys_nid = NUMA_NO_NODE;
>> +	for (i = 0; i < ARRAY_SIZE(emu_nid_to_phys); i++) {
>> +		if (emu_nid_to_phys[i] != NUMA_NO_NODE) {
>> +			max_emu_nid = i;
>> +			if (dfl_phys_nid == NUMA_NO_NODE)
>> +				dfl_phys_nid = emu_nid_to_phys[i];
>> +		}
>> +	}
>> +	if (dfl_phys_nid == NUMA_NO_NODE) {
>> +		pr_warn("NUMA: Warning: can't determine default physical node, disabling emulation\n");
>> +		goto no_emu;
>> +	}
>> +
>
>Well, that function numa_emulation() does a looot of things and could
>very well be split into subfunctions, which should make the whole path
>more readable.
>

You are right. The whole function contains several blocks which could be
split. While this patch focus on the memory leak issue. For readable code, we
could come up with a separate patch to refine it.

>And this chunk you're moving is kinda begging to be a separate
>function...

Well, to this particular piece, have a for loop within a function doesn't look
like a big deal to me. So you prefer to take every for loop in this function
out?

Last but not the least, these are two issues:

The problem this patch wants to address is the memory leak, while the concern
here you mentioned is the coding style.

>
>-- 
>Regards/Gruss,
>    Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

-- 
Wei Yang
Help you, Help me

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)