Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758398AbcC2Xft (ORCPT ); Tue, 29 Mar 2016 19:35:49 -0400 Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:34944 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752393AbcC2Xfr (ORCPT ); Tue, 29 Mar 2016 19:35:47 -0400 Date: Tue, 29 Mar 2016 18:35:45 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@east.gentwo.org To: Ajay Patel cc: linux-kernel@vger.kernel.org, penberg@kernel.org, brouer@redhat.com, rientjes@google.com, iamjoonsoo.kim@lge.co Subject: Re: 3.14.65: Memory leak when slub_debug is enabled In-Reply-To: Message-ID: References: Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 866 Lines: 21 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().