linux-kernel - Re: [PATCH 2/4] kmemleak: Handle percpu memory allocation

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]

Date:	Thu, 29 Sep 2011 12:28:18 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	linux-kernel@...r.kernel.org, Huajun Li <huajun.li.lee@...il.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [PATCH 2/4] kmemleak: Handle percpu memory allocation

Hello,

On Thu, Sep 29, 2011 at 12:02:28PM +0100, Catalin Marinas wrote:
> This patch adds kmemleak callbacks from the percpu allocator, reducing a
> number of false positives caused by kmemleak not scanning such memory
> blocks. The percpu chunks are never reported as leaks because of current
> kmemleak limitations with the __percpu pointer not pointing directly to
> the actual chunks.
...
> @@ -801,7 +804,16 @@ area_found:
>  	mutex_unlock(&pcpu_alloc_mutex);
>  
>  	/* return address relative to base address */
> -	return __addr_to_pcpu_ptr(chunk->base_addr + off);
> +	ptr = __addr_to_pcpu_ptr(chunk->base_addr + off);
> +
> +	/*
> +	 * Percpu allocations are currently reported as leaks (kmemleak false
> +	 * positives). To avoid this, just set min_count to 0.
> +	 */
> +	for_each_possible_cpu(cpu)
> +		kmemleak_alloc(per_cpu_ptr(ptr, cpu), size, 0, GFP_KERNEL);
> +
> +	return ptr;

I'm pretty ignorant about kmemleak but it scans memories looking for
references to allocated objects, right?  There currently is no way for
such scanner to tell a percpu pointer in memory from a regular pointer
making it impossible to track percpu objects properly from kmemleak.
If my understanding is correct, I don't see much point in tracking
each percpu alloc/free.  Why not just mark all pages taken by percpu
allocator as untrackable?

If we want to track percpu memory leak properly, I think we'll need
more invasive changes.  If kmemleak is enabled, we can offset percpu
pointer so that the scanner can tell percpu pointers and then kmemleak
should properly account for all percpu areas pointed to by the percpu
pointer.  Hmmm... or, alternatively, we can make kmemleak only track
allocations for the first possible cpu and ignore all the rest and
modify percpu such that percpu pointer points to the actual address of
the first cpu if kmemleak is enabled.

Thank you.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/