Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1366792 > unrolled thread

Re: 3.14.65: Memory leak when slub_debug is enabled

Started byChristoph Lameter <cl@linux.com>
First post2016-03-30 01:40 +0200
Last post2016-03-30 01:40 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: 3.14.65: Memory leak when slub_debug is enabled Christoph Lameter <cl@linux.com> - 2016-03-30 01:40 +0200

#1366792 — Re: 3.14.65: Memory leak when slub_debug is enabled

FromChristoph Lameter <cl@linux.com>
Date2016-03-30 01:40 +0200
SubjectRe: 3.14.65: Memory leak when slub_debug is enabled
Message-ID<riboS-53f-15@gated-at.bofh.it>
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().

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web