Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp134513pxa; Fri, 31 Jul 2020 08:10:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjblzDUqfF2yM0gVzGcOhQg+v/LMxZw6bsZSmgkQgfU0VBiOJIEDFPCr6jd953n2ry3qWR X-Received: by 2002:a17:906:37d1:: with SMTP id o17mr4700801ejc.98.1596208204229; Fri, 31 Jul 2020 08:10:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596208204; cv=none; d=google.com; s=arc-20160816; b=vRzZxiQ4wEQpFlBVn+WAU70nlyNscEjg7bNF/RoivK3Ar6Uwj3u+cMDkU4QqN03BWc a8waN5re4YGLqpSvjnuI5EQuP3w8naaz9GmkHUYJpno2VbCq8sEdsUwS8dDxTAl8q/wU P0rXuA6k6/GjIyTZ1n7Z602up/aiCK+CLCSjghPUySvFW22I6GCCqvLnfNukP8Sorg8B NpSRlpcmXRt7e34zucfAr3LnjrbdIpiL8Hv+QrPbFAIBURmGRusT9dUKDMts+6gbM9tK YLBG60PEszlQ+n+UDDUIywuNQQfVMmN9h1n4FKsXXyyOws4goU8L0hH5+8rzi28iHVWw +BIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Ff/aO+f/ar+IJTfIhhVDXCQGW8FBVjjCHNkbg+nD/8E=; b=f5jxmczAbV49356/Pvhp4lASmtDuhrEoitJgWUCdCXrSSxPu073IoMgeNaWKScXJ7b TuDfp1XxZY3aWjVWGtPqdgZnAaMcVfuj8x6ZdkrlEBjCTMZCaO2SEeCiprQhWU11eMtG NUiw9jpPCi4RzPo0yUquI0N+kFvx/dCyNkRVTHlFSw1ly0DjkEF9CwvYPsJDVKdNcJM+ 0GXLC25gG5GiT4Ner/h+wYcjJOfBSYBa6UHCvrh+MPe+DhEXYMU3T6hQslgwNnDJiVJ5 Hzka+/V1YYJYv4SWK7661AHBOyrluE9R2ZVOcIc7sIazraPPPeE426svY0hFPyYVvCii brFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=xVA3qKqV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e12si5346130edy.213.2020.07.31.08.09.39; Fri, 31 Jul 2020 08:10:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=xVA3qKqV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729292AbgGaPGE (ORCPT + 99 others); Fri, 31 Jul 2020 11:06:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728697AbgGaPGD (ORCPT ); Fri, 31 Jul 2020 11:06:03 -0400 Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8444C061574 for ; Fri, 31 Jul 2020 08:06:02 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id 2so24927008qkf.10 for ; Fri, 31 Jul 2020 08:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Ff/aO+f/ar+IJTfIhhVDXCQGW8FBVjjCHNkbg+nD/8E=; b=xVA3qKqVLrnkHInB3M7U9/5AssU33ep3UEX72ANbYHcwn7OdX9zg75cCCV7x/K2nNa b1BIUmYVhQ7WXkyZkU20DceV3dopjAeMrAqc2guZzTsxJinRGmeOl9Ymg0mAxJlfZqyX dwYhfdty5kF+PHCke0BmgkWLyX4hgJK6CLfLeqvkyR/Mg0M3JCELG8YsRUM4qlT+X8Qj 9dTTHJrGLhq3YOeye2px9l1Reimwbd2nbkT2ixMLy2gWMOJOSQYVmNt5m4cCvztQvyg3 HRo6Eepk55mVeW4q8dcoYYcxuHuazDbeAHUB8zx6SZfLv8OH7zA/kqP9jAj1lVyy234I Vr2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Ff/aO+f/ar+IJTfIhhVDXCQGW8FBVjjCHNkbg+nD/8E=; b=qwsYix9lmMyCOE8uf8w/802ZOOdyAAnaf51Ivji1bvQvMqaafvzilxf7dTlTjlFqzX huiIMfbsyBYUCmjOSrF80PzCuLw2TZnOMyQmTX5aVAEcemmyCv4MT/zfI0flxprbS0hg 2CTvUeEwaLyPZaeCaTzT9FlpeO3oYIJCijqHGZAiPsrzocEFtNho5YItyvUFBU1hVyEX k5zTJlO2ZiceK6nQUaGz848F7fDA+7Jg8+7N6nF/TOFg/3N9YtqTgq/Sy0q5j21lUvIA IdQ8Yu9SybBPjHHOwsZkDBCbdxomSW55YQPR04N/yOC8FSbB/F7IoFmWhlsizzRboP3x 6k4w== X-Gm-Message-State: AOAM5314wKgit+372PRZjMsDphrG6A6QKc2YUbadQZ5WnESKZ2/6VirG 072hPH+OYysBl6fGyg+TTGyJBg== X-Received: by 2002:a37:a0d3:: with SMTP id j202mr4242255qke.365.1596207961101; Fri, 31 Jul 2020 08:06:01 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:11a4]) by smtp.gmail.com with ESMTPSA id w11sm9365133qtc.58.2020.07.31.08.05.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2020 08:06:00 -0700 (PDT) Date: Fri, 31 Jul 2020 11:04:58 -0400 From: Johannes Weiner To: Hugh Dickins Cc: Andrew Morton , Roman Gushchin , Shakeel Butt , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm] mm: memcontrol: decouple reference counting from page accounting fix Message-ID: <20200731150458.GA491801@cmpxchg.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 08:17:50PM -0700, Hugh Dickins wrote: > Moving tasks between mem cgroups with memory.move_charge_at_immigrate 3, > while swapping, crashes soon on mmotm (and so presumably on linux-next): > for example, spinlock found corrupted when lock_page_memcg() is called. > It's as if the mem cgroup structures have been freed too early. > > Stab in the dark: what if all the accounting is right, except that the > css_put_many() in __mem_cgroup_clear_mc() is now (worse than) redundant? > Removing it fixes the crashes, but that's hardly surprising; and stats > temporarily hacked into mem_cgroup_css_alloc() and mem_cgroup_css_free() > showed that mem cgroups were not being leaked with this change. > > Note: this removes the last call to css_put_many() from the tree; and > mm-memcg-slab-use-a-single-set-of-kmem_caches-for-all-accounted-allocations.patch > removes the last call to css_get_many(): now that their last references > have gone, I expect them soon to be freed from include/linux/cgroup.h. > > Signed-off-by: Hugh Dickins Thanks, Hugh. This fix looks correct to me. And I'd agree with the put being worse than redundant. Its counterpart in try_charge() has been removed, so this a clear-cut ref imbalance. When moving a task between cgroups, we scan the page tables for pages and swap entries, and then pre-charge the target group while we're still allowed to veto the task move (can_attach). In the actual attach step we then reassign all the pages and swap entries and balance the books in the cgroup the task emigrated from. That precharging used to acquire css references for every page charge and swap entry charge when calling try_charge(). That is gone. Now we move css references along with the page (move_account), and swap entries use the mem_cgroup_id references which pin the css indirectly. Leaving that css_put_many behind in the swap path was an oversight. Acked-by: Johannes Weiner > --- > Fixes mm-memcontrol-decouple-reference-counting-from-page-accounting.patch > > mm/memcontrol.c | 2 -- > 1 file changed, 2 deletions(-) > > --- mmotm/mm/memcontrol.c 2020-07-27 18:55:00.700554752 -0700 > +++ linux/mm/memcontrol.c 2020-07-30 12:05:00.640091618 -0700 > @@ -5887,8 +5887,6 @@ static void __mem_cgroup_clear_mc(void) > if (!mem_cgroup_is_root(mc.to)) > page_counter_uncharge(&mc.to->memory, mc.moved_swap); > > - css_put_many(&mc.to->css, mc.moved_swap); > - > mc.moved_swap = 0; > } > memcg_oom_recover(from);