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] [day] [month] [year] [list]

Message-ID: <CADZGycYRFNKuJeySkt_dk+pFpvoR_0DT_xmWGcw=EH49gDpfwA@mail.gmail.com>
Date:   Wed, 28 Jun 2017 07:37:16 +0800
From:   Wei Yang <richard.weiyang@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Kirill A. Shutemov" <kirill@...temov.name>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Tejun Heo <tj@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 1/3] x86/numa_emulation: fix potential memory leak

On Wed, Jun 28, 2017 at 2:10 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Tue, Jun 27, 2017 at 07:11:27AM +0800, Wei Yang wrote:
>> It means numa emulation is not properly configured.
>
> Or what the error message says: it cannot determine the default physical
> node because NUMA emulation is not properly configured. What I'm trying
> to say, is, explain the *why* in the commit message, not the *what*. The
> *what* one can see in the code.
>

I didn't dig into the reason for when this could happen.

After some investigation, it looks will not happen after split_nodes_xxx()
works fine. In function split_nodes_xxx(), if it doesn't return an error code
it will set the emu_nid_to_phys[]. Which in turns be assigned to dfl_phys_nid.

So I suggest to remove the error branch.

>> 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?
>
> As I said, I'd prefer you take this loop out and turn it into a separate
> function in one go, along with fixing the potential memory leak.
>
>> 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.
>
> Let's not get too pedantic here: if you carve it out in a separate
> function, it is still clear what the patch is doing.
>

Ok, will do this.

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