From patchwork Wed Jan 9 04:01:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rik van Riel X-Patchwork-Id: 10753393 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D3A2713B4 for ; Wed, 9 Jan 2019 04:01:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C1F0328C0C for ; Wed, 9 Jan 2019 04:01:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B3D6128D59; Wed, 9 Jan 2019 04:01:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E39CB28C0C for ; Wed, 9 Jan 2019 04:01:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72E208E009D; Tue, 8 Jan 2019 23:01:29 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 6DD048E0038; Tue, 8 Jan 2019 23:01:29 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CC868E009D; Tue, 8 Jan 2019 23:01:29 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by kanga.kvack.org (Postfix) with ESMTP id 2CE128E0038 for ; Tue, 8 Jan 2019 23:01:29 -0500 (EST) Received: by mail-qk1-f200.google.com with SMTP id f22so5026615qkm.11 for ; Tue, 08 Jan 2019 20:01:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id:sender; bh=6VYFUOUu3LRs9/mWMMuJ59v1pUwREqv5OzKnMe/+QS8=; b=KB3R/lye+XAoVf44X4xhGAJ5KRM6TUXknZfpgxdRNtoy5KT59L7DjDo+R4Xs46vEey trW1Y9n+xxf3t1K7ooQcoV6CELmSsnF6/fMMzsKR1I5vBv1bEY1MY8d6zqBGryLY5TfF S4YdkBILtBBCrLwNnoQ0V9/mNiLX8gH+V9dC6+Lldc9VXXw9mmyC8KPoe9J3UE8i3pm6 0qk2d/7xzvSx7q2ff1hzUjhz8I2Q7k5OUhJuLSdDfDjon4dStCZNsUTAzLc3Cl9dTdww 0NhNIXoSYdUJ2nX4jB5LQ85/6A6sB4HGgx77RRChKIhsIb/2/0x0PJ0eOUIeXAdlIER9 MIUw== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com X-Gm-Message-State: AJcUukcY8xPkM+eEh1EjW8lvFKxWFQY7mHmMrgH+leHy1+D/3/VM1MtJ Fi5HfgzOKzT4DEYQoVVl0mZG2jRIpbyJeh9p3O5jKUqm7TyK6xShw9u1RkpQrc3ssLvb5Qu93Av pAXYu5LxUPZ9V6MVNLqv2UijfspA7A2Ripy4ppb5I16eKQTJDUhYC5Sikq5QkuZAoaA== X-Received: by 2002:a37:4651:: with SMTP id t78mr3931360qka.210.1547006488912; Tue, 08 Jan 2019 20:01:28 -0800 (PST) X-Google-Smtp-Source: ALg8bN7A6i3GyPafLQHo+k1XzpWtc77P2DopPTLihD8uxdvWkqoYTY4XR+5SYDP3exR29h7BR0VB X-Received: by 2002:a37:4651:: with SMTP id t78mr3931316qka.210.1547006487795; Tue, 08 Jan 2019 20:01:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547006487; cv=none; d=google.com; s=arc-20160816; b=i3gA9pFHO2sJB2E0liA5k7BHsX9ZmGgebeEBMI3BlOLxcSM5pHDaLSUfMNcloeIEfc 67NQyaQ7tbWTQfbWAYvhvb99yWwkk5yVZknEX/2tLmt7WI20KQCYMLOm6CVNaIuzRMhz Lp1m6RuKCxs3gxQVQuxijQM5x4oRI659Himqm5wAPxUDwwDMy49j81ztqFgz+N02vreH 7r7WomqDQ4Uv49AU2MzGdulOU2Rdy8VDUJt4daxFUZ3KifL6ywSwrKELrT+cPsPR1Ho9 mNFYeT4wPnEYBYeRsBoOll6EIC9GnKM3UOiFs/GCcqZMDvEXoaFuzUCOCGa0bb3CzuUq 6caA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:message-id:date:subject:cc:to:from; bh=6VYFUOUu3LRs9/mWMMuJ59v1pUwREqv5OzKnMe/+QS8=; b=Kyruh4FGV/S1Aq1avHz2iMx3ivQjMfYgcJe2EYGtGN9khIjOUTAPcvkNgFgvrFuNub fQPgJDq5rnA4S7JJWf708k25dVHdqJwlKUUTm0vWBu0BKf945aFbVqIiJg/UoqBZt2a2 ASws9Kx4cSRsLn8Mmg5XQU3SX25JotE0mw4CPWMPdwk/47yOfqalSo3l1QS57ri5F1gN egx/m0Oi4uH6RKIJHYu7LDfpi1cAj0Tei4HXuqWflB6ZPJ28Z2ejqld08DPf7e1OcEMh m0zj3Mcd7jHMy8pj116B04zmZuzkh3IpdySuzA6+cFIJngE1IJX2x0qvIyBCFmlgWtEI X8kQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com Received: from shelob.surriel.com (shelob.surriel.com. [96.67.55.147]) by mx.google.com with ESMTPS id q45si738869qte.344.2019.01.08.20.01.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jan 2019 20:01:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) client-ip=96.67.55.147; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gh53I-0006Hz-B2; Tue, 08 Jan 2019 23:01:12 -0500 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: Rik van Riel , kernel-team@fb.com, linux-mm@kvack.org, stable@vger.kernel.org, Alexey Dobriyan , Christoph Lameter , Pekka Enberg , Andrew Morton , David Rientjes , Joonsoo Kim , Johannes Weiner , Tejun Heo Subject: [PATCH] mm,slab,memcg: call memcg kmem put cache with same condition as get Date: Tue, 8 Jan 2019 23:01:07 -0500 Message-Id: <20190109040107.4110-1-riel@surriel.com> X-Mailer: git-send-email 2.17.1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP There is an imbalance between when slab_pre_alloc_hook calls memcg_kmem_get_cache and when slab_post_alloc_hook calls memcg_kmem_put_cache. This can cause a memcg kmem cache to be destroyed right as an object from that cache is being allocated, which is probably not good. It could lead to things like a memcg allocating new kmalloc slabs instead of using freed space in old ones, maybe memory leaks, and maybe oopses as a memcg kmalloc slab is getting destroyed on one CPU while another CPU is trying to do an allocation from that same memcg. The obvious fix would be to use the same condition for calling memcg_kmem_put_cache that we also use to decide whether to call memcg_kmem_get_cache. I am not sure how long this bug has been around, since the last changeset to touch that code - 452647784b2f ("mm: memcontrol: cleanup kmem charge functions") - merely moved the bug from one location to another. I am still tagging that changeset, because the fix should automatically apply that far back. Signed-off-by: Rik van Riel Fixes: 452647784b2f ("mm: memcontrol: cleanup kmem charge functions") Cc: kernel-team@fb.com Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Cc: Alexey Dobriyan Cc: Christoph Lameter Cc: Pekka Enberg Cc: Andrew Morton Cc: David Rientjes Cc: Joonsoo Kim Cc: Johannes Weiner Cc: Tejun Heo --- mm/slab.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/slab.h b/mm/slab.h index 4190c24ef0e9..ab3d95bef8a0 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -444,7 +444,8 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s, gfp_t flags, p[i] = kasan_slab_alloc(s, object, flags); } - if (memcg_kmem_enabled()) + if (memcg_kmem_enabled() && + ((flags & __GFP_ACCOUNT) || (s->flags & SLAB_ACCOUNT))) memcg_kmem_put_cache(s); }