Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2728232imm; Sun, 30 Sep 2018 03:42:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV60iwELP8rdhPKs4i0PQPSFFhcPllmqm2hu6IeFG1m6lhPPle/bTyK+g4UzwRNlU3NdELmas X-Received: by 2002:a17:902:9a8f:: with SMTP id w15-v6mr498675plp.41.1538304126953; Sun, 30 Sep 2018 03:42:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538304126; cv=none; d=google.com; s=arc-20160816; b=OZQb4AEX5C6v+tyVX2fF7OtDMD3KerJa/SAVpkIo89vH5FF4jShJ0libvumTVhvPMV DUbnIGaNJ2ks3spr8BsC4vmgOXz97GVo2EWLQ6h9szy600kp4ogqaWPNcWPE03Dp9KRa 6KsPL3RIiGQpr3zkii8CA5tkJFk2sScamDLgfMZ4yaM7Kw2PibxFChK16lMZlRyjbeLr RsUlWyZSpDA67bcPthsWpt84PkK5KOgx1tp5o5HZM+l1DMPpiVQqIcJzvxako+ui7OX4 XDilyyx8IVyn/8trWxtv/aevZDd722PDL0T/6m2nFNuUfFBYjJHzL61IK5w+zECp7T1S KWWQ== 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=okSCPUvl/SmjCXjmfUt86F4rf5l9sFnpEAiatPdv3TQ=; b=rrF3NZx7MNZsOjDmvd/62OkRLvwph4c6w+Dt4mHXY4iujLcYJWQ9M9dt+ijxg03DSu PXq8gC4wwFDYCBPLhBpU8e0rCim8n7gYT6Sz/qadNRXSPgDseCJVITAR8VPm8w7ylNvd S3en9gQz4CkJfmmuB7eDhrwzpZUdl9mekEshe6cn7VPDKaSQ96EtZ8FvGarVSPuR0atj xkRBRNjbbPUl9/cyeDBpB6GbbNIEhgiYr/3VkJr/u3VFt5YQ2dY+YXdYCgeJ7YEvXPDq 6xoQm8d4pGrPbQCtzC5PDSp+vKaaSaoFPOVUTkU9PKbtVSr/MyYDYLadAFveEWyh5rvo qBqw== 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 q1-v6si10065011pfb.258.2018.09.30.03.41.52; Sun, 30 Sep 2018 03:42:06 -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 S1728455AbeI3RNa (ORCPT + 99 others); Sun, 30 Sep 2018 13:13:30 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:53076 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727821AbeI3RNa (ORCPT ); Sun, 30 Sep 2018 13:13:30 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 9462E810E0566; Sun, 30 Sep 2018 18:40:56 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.399.0; Sun, 30 Sep 2018 18:40:54 +0800 From: zhong jiang To: CC: , , , , , , , , , , , Subject: [STABLE PATCH] slub: make ->cpu_partial unsigned int Date: Sun, 30 Sep 2018 18:28:21 +0800 Message-ID: <1538303301-61784-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 [ Upstream commit e5d9998f3e09359b372a037a6ac55ba235d95d57 ] /* * 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. Becuase 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. 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. Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobriyan@gmail.com Signed-off-by: Alexey Dobriyan Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: # 4.4.x 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