Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp357250imu; Tue, 8 Jan 2019 21:57:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN713hkirg6dEW/9rBwFgk/BVOyzRjRxaNW+neMu8W8/QWfTKNZPujEOYq9vTsTW3TWwFRqu X-Received: by 2002:a63:5c22:: with SMTP id q34mr4158136pgb.417.1547013440910; Tue, 08 Jan 2019 21:57:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547013440; cv=none; d=google.com; s=arc-20160816; b=uixDJBX49zsr8rxfs/ny/d2owvM/4afMYCqdG6tInMKnqWXM7NH3wDeIgm42Jxy8OC M8Jgs+oCC77/2j19i5mYsB5mmYC0k3CUeVTWPF/dgBKdpLuOsoaY836FJN1Sb9bPz1oZ be+obFcfURq+VG7OtkN9PjZgEThm70Qt+QNdufpZzniyFnyWtEEukQRxE3iRsjZCI1R4 lqce5yPO7SaXeglgEdl24AE4pLBkfxplOdk3QZ/Vbp+6vK+J11uHtwc81vqT7gsXwUgI jI8FR7YfByAb/yhs0o6XLKxhJjR3r32MAPJC7e8gwuV5U1VLIwe5WkoDVVgLoWNxa+02 MNgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6nHgzPv8OHHMQOhvL9odj368V6gyeIizn/EW268BFmo=; b=GV8Nhwrb6bcpc+gDrGpsBd069tC83p4SPZjbb9xqPxil55NN2IyFsXrKuy4DfGqH0o ppqWmgRzpUfCZCZNdeT2+ARDzRDW4009KrpkIZ8B9f2fFh8CXSEEZxih9nXPVdmPhkep ZJr8Yiy2WaA+KiO4++7X3+swTvXGdZcQqOimRkK74DgGr4V5KSGdalhu9UHIAV4cDBXW 8w0oneLJabPvUIsatpKTA+mMTm0vFw3GhrEU45JVzvrN3/R/HXlwUjxDaf9xMXsU1YUD 4Mx4VnXDjt3W8+8zXFsW8zZsKemlwne9wFk87R5zblNIT6QImzKJObWZfDUXJf1alfps A6/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=T+BtHPWA; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v185si15378994pfb.65.2019.01.08.21.57.05; Tue, 08 Jan 2019 21:57:20 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=T+BtHPWA; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729550AbfAIFoo (ORCPT + 99 others); Wed, 9 Jan 2019 00:44:44 -0500 Received: from mail-yb1-f196.google.com ([209.85.219.196]:32964 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725440AbfAIFoo (ORCPT ); Wed, 9 Jan 2019 00:44:44 -0500 Received: by mail-yb1-f196.google.com with SMTP id o73so2567804ybc.0 for ; Tue, 08 Jan 2019 21:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6nHgzPv8OHHMQOhvL9odj368V6gyeIizn/EW268BFmo=; b=T+BtHPWAN7zFhlQJ3Vh7wdCJ+9Db2lsKHltj0bZCAebH1WiEy/bGepN15kGNiU6469 ma5r8vkSiWbBVxLwouI02LIchw3YoIyHYBRZwkB5Mi09ldoK0U4m4ykkg5iORhBPlrPh g1WBZrFyVRuFCEyVU3B6VRzFk0aUui5Hr22SMVyzXMDfAkmF4CdNPksyjrJumw0d4q4D 93Ro/R63gHWvIeT4IwK7z2HTr+0dokmPc2Cwsj47wUMBzNlbRFkDi5tOyOnI90QT9+Wi m9V53rJfzirHyQAUR3sIjq1htXAy4TLE2wChDX4H9psoaB26huD3zIy+8n0ZD0i+c+H+ 0rEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6nHgzPv8OHHMQOhvL9odj368V6gyeIizn/EW268BFmo=; b=KFVDHoB6ckHsiWxZ/y42aAn1ZeZ15Es29Br5KMtmDP11dVcBL/WXEwOZiLXsLDJG8t ce/c5rRotRI7t0bA6qovxAomnJ6y73WvKNxiAhQmnyfLgFRrvvnLlYI4fYAdRbShETuo rmOJJwp99Jai5z/R10f8ycV+HZnsWAQPD3sdSw46A/zt7HGyw9Bq02b0Hw9Qpj/uUP0R mwW+dshAtBgHEVc+oIzuh//fgsUFBEiJwP935aFvGMmWBHiWF9AJrcvbHbYzqHItvy4+ zBzqSM30O2GAThNE5I8kH/K5Rh/g/dUtbXVWaKUlegQ0qyi5eU7Bw4E6mgOywW8L6+Vx N5bQ== X-Gm-Message-State: AJcUuke/k8tXp7kC/Af+Wbs+AjIxqf4wIrPYsLb5Ngk1DT9cb1HjO6xz C75cU77ppkq+w91yuWihfLrOhuL1FfOs/pmEIApcAO0LpNI2og== X-Received: by 2002:a25:26c8:: with SMTP id m191mr4384247ybm.377.1547012683115; Tue, 08 Jan 2019 21:44:43 -0800 (PST) MIME-Version: 1.0 References: <20190109040107.4110-1-riel@surriel.com> In-Reply-To: From: Shakeel Butt Date: Tue, 8 Jan 2019 21:44:32 -0800 Message-ID: Subject: Re: [PATCH] mm,slab,memcg: call memcg kmem put cache with same condition as get To: Rik van Riel Cc: LKML , kernel-team@fb.com, Linux MM , stable@vger.kernel.org, Alexey Dobriyan , Christoph Lameter , Pekka Enberg , Andrew Morton , David Rientjes , Joonsoo Kim , Johannes Weiner , Tejun Heo Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 8, 2019 at 9:36 PM Shakeel Butt wrote: > > On Tue, Jan 8, 2019 at 8:01 PM Rik van Riel wrote: > > > > 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. > > > > Can you explain how there is an imbalance? If the returned kmem cache > from memcg_kmem_get_cache() is the memcg kmem cache then the refcnt of > memcg is elevated and the memcg_kmem_put_cache() will correctly > decrement the refcnt of the memcg. > > > This can cause a memcg kmem cache to be destroyed right as > > an object from that cache is being allocated, Also please note that the memcg kmem caches are destroyed (if empty) on memcg offline. The css_tryget_online() within memcg_kmem_get_cache() will fail. See kernel/cgroup/cgroup.c * 2. When the percpu_ref is confirmed to be visible as killed on all CPUs * and thus css_tryget_online() is guaranteed to fail, the css can be * offlined by invoking offline_css(). After offlining, the base ref is * put. Implemented in css_killed_work_fn(). > > 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))) > > I don't think these extra checks are needed. They are safe but not needed. > > > memcg_kmem_put_cache(s); > > } > > > > -- > > 2.17.1 > > > > thanks, > Shakeel