linux-kernel - Re: [RFC PATCH 1/1] mm/percpu.c: fix potential memory leakage for pcpu_embed_first

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: <20160930084323.GC29207@mtj.duckdns.org>
Date:   Fri, 30 Sep 2016 10:43:23 +0200
From:   Tejun Heo <tj@...nel.org>
To:     zijun_hu <zijun_hu@...o.com>
Cc:     zijun_hu@....com, Andrew Morton <akpm@...ux-foundation.org>,
        cl@...ux.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] mm/percpu.c: fix potential memory leakage for
 pcpu_embed_first_chunk()

Hello,

On Fri, Sep 30, 2016 at 01:38:35AM +0800, zijun_hu wrote:
> 1) the simpler way don't work because it maybe free many memory block twice

Right, the punched holes.  Forgot about them.  Yeah, that's why the
later failure just leaks memory.

> 2) as we seen, pcpu_setup_first_chunk() doesn't cause a failure, it  return 0
>    always or panic by BUG_ON(), even if it fails, we can conclude the allocated
>    memory based on information recorded by it, such as pcpu_base_addr and many of
>    static variable, we can complete the free operations; but we can't if we
>    fail in the case pointed by this patch

So, being strictly correct doesn't matter that much here.  These
things failing indicates that something is very wrong with either the
code or configuration and we might as well trigger BUG.  That said,
yeah, it's nicer to recover without leaking anything.

> 3) my test way is simple, i force "if (max_distance > VMALLOC_TOTAL * 3 / 4)"
>    to if (1) and print which memory i allocate before the jumping, then print which memory
>    i free after the jumping and before returning, then check whether i free the memory i 
>    allocate in this function, the result is okay

Can you please include what has been discussed into the patch
description?

Thanks.

-- 
tejun