linux-kernel - Re: 3.14.65: Memory leak when slub

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

Date:	Tue, 29 Mar 2016 18:35:45 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Ajay Patel <patela@...il.com>
cc:	linux-kernel@...r.kernel.org, penberg@...nel.org,
	brouer@...hat.com, rientjes@...gle.com, iamjoonsoo.kim@....co
Subject: Re: 3.14.65: Memory leak when slub_debug is enabled

On Tue, 29 Mar 2016, Ajay Patel wrote:

> We have custom board with Marvell Armada dual core ARMV7.
> The driver uses buffers from kmalloc-8192 slab heavily.
> When slub_debug is enabled, the kmalloc-8192 active slabs are
> increasing. The slub stats shows  cmpxchg_double_fail and objects_partial
> are increasing too. Eventually system panics on oom.

Hmmm... I thought we fall back to pass through to the page allocator for
order 1 requests? Why is it going through the regular allocator paths?

> Following patch fixes the issue.

Wonder how that could be? Does the __cmpxchg_double work correctly on ARM?

> Has anybody encountered this issue?
> Is this right fix?

Looks like something is screwing around with the page flags because an
order 1 page is a compound page? Can you ensure that order 1 allocs are
using page allocator fallback. See kmalloc_large().