Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2133225imm; Thu, 27 Sep 2018 07:57:11 -0700 (PDT) X-Google-Smtp-Source: ACcGV63IkkpDqV5WcIWoQOPNgKPllMnI0IQFwL1dcldNMddXgXIYg+4HdJ9Aau35kCD0r/Zu4C++ X-Received: by 2002:a17:902:a504:: with SMTP id s4-v6mr11843121plq.101.1538060231882; Thu, 27 Sep 2018 07:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538060231; cv=none; d=google.com; s=arc-20160816; b=uKS6aerHjgHj0yphfFd9sShgQRBLp0snuu+RAD5JzbKHtBKG9G4yFEt9k3k4kemPYJ 3WDKsd3muDbLHAdqMU5Dnyz/FM9q1fZ9a4JYqGctYioNPeNJVhSqKFyeC7VX2hTE9e3L mjO3ITXWoSZ1NbkCyc5r/m9lr/M62W/3E0moXbIAS1FoMJ1FqYSSbhKMHIMbJzZc23CW rwNEf+ctm5Cuq5lX8l76wsOTkxVwZv93JmvlOOLBrLl7oDqtlNdh7xynonBidjPyKAHX eCWI2V4XpuUUtllsmOw68OnbQ5KMpWQoF45K/RZM13fOxxLOgz8xMSRZkgrcg3Mficar xpZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=FrdmwLopomqWB5p0kfTiAwk/aguq5sJFbpsXF+9YKLg=; b=no6GDlDbMrE1alKsC7MZ/7Pa34dNsdsZo8aja5m+RqnzeV5D4/h46GrmanPi2BVV3F Xxfj83LVxK4dN13T/PWgdPwLaCi709DE7gXXVecNGNzcuezyLFe/eyFWOO005+TlcJ18 6eVjU+EnBHZDi3tHbwJNDzxm16EcaS5idb37qSGG+nLZmyazIRaaNQKR824gmRuprEuk +Uk89zWHF3qnmENfiEZTGwLdFufdP/dGVI2y1LYO50tVfvVXgoksDi8YpOYP4mM5sgvi taagtZTAXXRFHCqQR4aFRzbqMe7UlmC7dufYaOXUjkC2Ox+fxuf99bNUxF8ImHgxP/HO qpuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 43-v6si2355173plb.444.2018.09.27.07.56.56; Thu, 27 Sep 2018 07:57:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727534AbeI0VOz (ORCPT + 99 others); Thu, 27 Sep 2018 17:14:55 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:50215 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727270AbeI0VOy (ORCPT ); Thu, 27 Sep 2018 17:14:54 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 3F8919E1510C6; Thu, 27 Sep 2018 22:56:09 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.399.0; Thu, 27 Sep 2018 22:56:08 +0800 From: zhong jiang To: CC: , , , , , , , , Subject: [STABLE PATCH] slub: make ->cpu_partial unsigned int Date: Thu, 27 Sep 2018 22:43:40 +0800 Message-ID: <1538059420-14439-1-git-send-email-zhongjiang@huawei.com> X-Mailer: git-send-email 1.7.12.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alexey Dobriyan /* * cpu_partial determined the maximum number of objects * kept in the per cpu partial lists of a processor. */ Can't be negative. I hit a real issue that it will result in a large number of memory leak. Because Freeing slabs are in interrupt context. So it can trigger this issue. put_cpu_partial can be interrupted more than once. due to a union struct of lru and pobjects in struct page, when other core handles page->lru list, for eaxmple, remove_partial in freeing slab code flow, It will result in pobjects being a negative value(0xdead0000). Therefore, a large number of slabs will be added to per_cpu partial list. I had posted the issue to community before. The detailed issue description is as follows. Link: https://www.spinics.net/lists/kernel/msg2870979.html After applying the patch, The issue is fixed. So the patch is a effective bugfix. It should go into stable. Signed-off-by: Alexey Dobriyan Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: zhong jiang --- include/linux/slub_def.h | 3 ++- mm/slub.c | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index 3388511..9b681f2 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -67,7 +67,8 @@ struct kmem_cache { int size; /* The size of an object including meta data */ int object_size; /* The size of an object without meta data */ int offset; /* Free pointer offset. */ - int cpu_partial; /* Number of per cpu partial objects to keep around */ + /* Number of per cpu partial objects to keep around */ + unsigned int cpu_partial; struct kmem_cache_order_objects oo; /* Allocation and freeing of slabs */ diff --git a/mm/slub.c b/mm/slub.c index 2284c43..c33b0e1 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1661,7 +1661,7 @@ static void *get_partial_node(struct kmem_cache *s, struct kmem_cache_node *n, { struct page *page, *page2; void *object = NULL; - int available = 0; + unsigned int available = 0; int objects; /* @@ -4674,10 +4674,10 @@ static ssize_t cpu_partial_show(struct kmem_cache *s, char *buf) static ssize_t cpu_partial_store(struct kmem_cache *s, const char *buf, size_t length) { - unsigned long objects; + unsigned int objects; int err; - err = kstrtoul(buf, 10, &objects); + err = kstrtouint(buf, 10, &objects); if (err) return err; if (objects && !kmem_cache_has_cpu_partial(s)) -- 1.7.12.4