From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A630EE4998 for ; Fri, 18 Aug 2023 22:19:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25A0394007B; Fri, 18 Aug 2023 18:19:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2098C940012; Fri, 18 Aug 2023 18:19:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D22294007B; Fri, 18 Aug 2023 18:19:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id ED48B940012 for ; Fri, 18 Aug 2023 18:19:18 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BEC03B172E for ; Fri, 18 Aug 2023 22:19:18 +0000 (UTC) X-FDA: 81138642396.29.CBB317F Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by imf17.hostedemail.com (Postfix) with ESMTP id DF7C740015 for ; Fri, 18 Aug 2023 22:19:15 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=rDWfS1qg; spf=pass (imf17.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.161.45 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692397156; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hmpKIyAQ8RsIyIEMOMC7QqMJtydQ9V1xA5lN6gQxjZI=; b=PdsauPXw7KtdayYpDYDnX+Ufr2ZP6v1cIcmCus662YX3z92il63Du8HN7iFCCiafGRXoHH woTqC9QCRZcTiDuwhqIe4OeEq0UMJUw+3zieBH9ZzBahmdOanZaa6bMP1PwAhWRRbA8jnd fbDMXKu55sNMWMIxgfVRO4NeazylrJc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692397156; a=rsa-sha256; cv=none; b=e0d8oiPQlne/FZoaxSq7KCEuT9IOw5slAOwTob1cWcayYBEegxyScturYQ3TR2k3DpQjvZ eti1BK9IRzxNuG97jj1MNLCWfzlPoML02FqilJg73jvremmFrHb4dmConmO1JNeVmZ9yS+ dZfCs7FBowJA0hod6RGwcRI/vy13fZI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=rDWfS1qg; spf=pass (imf17.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.161.45 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-56cc461f34fso900396eaf.0 for ; Fri, 18 Aug 2023 15:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1692397155; x=1693001955; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=hmpKIyAQ8RsIyIEMOMC7QqMJtydQ9V1xA5lN6gQxjZI=; b=rDWfS1qgctml/CnDjcIdruBH+DHUCGbl85DmFlXB/3Rb4TZalsuBMBkcKe5rwOG/2d q11J5RVL2Nh/T5ca7d+YfO44YpB/y6Vj8RCzA7MmGI3ebcpF2CNKRcBf1WF3YSRTHN9t XRjr3lPJrmP0vBGvYrVC+KBesQD9ApDl2o1zdU5SL10jW3rWfTd8YVAbF86EpTusstrw 6gxji2eNBUIE9sigybwMoCwnpzMhHZKp12BG7G2ouWBobL+2wNU7U87YLpeMHLQyGnSG qzX3XHyI1s1Ux7P7jE2aqRsSHBafKPpXmfcASYxce8+0kpUiNyZoIbwshrygCQxg43Zr coNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692397155; x=1693001955; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hmpKIyAQ8RsIyIEMOMC7QqMJtydQ9V1xA5lN6gQxjZI=; b=g81Pr4gIJFdbxUW9Hyrdy+ArfnpnVah0GNrMv78yB7QVCeN5N+7Blj2JRM9QDLtfav As9+Y+qk+iaHcZvAnbXvYOBO7XHJRHRCOgAdesviYNoWxPb7EenLsH9bJbpd4OByMH3b SCnZJprE80rGc10BOeEuBf29iDhuvQdFAdfNQ0vHT2U28ED14HTjUsruJ5TXjk7RoFo7 2a4ySGH6RVCNvOxDoqpR2DbXRku7kPx3q5B063eDQr1KRv/ly3383D0pLigWt3BC8O0H Mzj8VeLRxEwnb8/KNkwP/1Stj90wixcWsqI4FWHcsgW+V6zJDi38/kQxvqLhcBsf3ViB oFew== X-Gm-Message-State: AOJu0YzdPGZo64/qN0q22A5YpnFQ/XK6+OhwNlRyQ2xakABJJtkGsbo8 3f+ZtI1Zj589LUZERhl1N46I+w== X-Google-Smtp-Source: AGHT+IGlY5jBVyHy6id4d2YSavOSbKGRT+TFNUDhCFs+bK5aqxjjPqXsb43+1mr0FR6EuLyJsll8cA== X-Received: by 2002:a05:6359:1b85:b0:139:e3a4:70a1 with SMTP id ur5-20020a0563591b8500b00139e3a470a1mr420297rwb.28.1692397154786; Fri, 18 Aug 2023 15:19:14 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:75e0]) by smtp.gmail.com with ESMTPSA id g22-20020a0caad6000000b006262de12a8csm981855qvb.65.2023.08.18.15.19.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Aug 2023 15:19:14 -0700 (PDT) Date: Fri, 18 Aug 2023 18:19:13 -0400 From: Johannes Weiner To: Yosry Ahmed Cc: Yu Zhao , Nhat Pham , akpm@linux-foundation.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH v2] workingset: ensure memcg is valid for recency check Message-ID: <20230818221913.GA144640@cmpxchg.org> References: <20230818134906.GA138967@cmpxchg.org> <20230818173544.GA142196@cmpxchg.org> <20230818183538.GA142974@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: DF7C740015 X-Rspam-User: X-Stat-Signature: ytd6nijfaar8xhh4gzs4k8yyiodcpknd X-Rspamd-Server: rspam03 X-HE-Tag: 1692397155-836127 X-HE-Meta: U2FsdGVkX19dtsMWqMToQcQOwnB+9j0HYA+uPwqT3BB8/xVPPD//jsRcyUqrNdzO31zYH4y21mq4Act+A7rrxg41iupNNVdJoxfM5eRTiodfCV2fjtPILJbWmkTSTfqNcQU7j+7ynbzNvGcI9p+Q/ZheXjeJ7dOAIUFS56eIrhaHR6UKt4TUcrNMeEEs39ceYRwyzG/OnaljkNuSxYVP7TIFHF0R5+yINQ0bemctgjzjqWBKERfGQgzMylZBZ3iCgNfI0sNn87TYiqEhXa+8ix19vQA+J8NGF6iUGQtmOJWefu3lA+m6aOZ5Z4jmUY1lN+rIQPQIM8Saql/U0J39IQtRutnsgnObuhqPOwXN2WLNVMYTG8iBCltnPxyCgrwvFG8UmR4K7QClqP0Ty6IdoH8NX+YlpqHuq2HPmM6j4IdJP4g84z5X+jW7I3f56OG/r8pIIvSoY0qldYAYj+ancCEdnaTIjUtHQ9RCk5jINhNxAh2LenRtLdEzjBjemOLxSOefSR60i9JAclHx9cbayZPuSof1iiOL33AHkFNtLYY275Pl6H0N2Y5draezhinaQtuCSdFw/8d9N2GzpTZ3A7Jpk95V3XAzVli3Bf7TpmQwKKhFAlg5YRWlMN2urltDSfP70iPmQci8CXSTXggAZV66T72BHuVt5LVkUVQ2Tvh3hFWWvh/tpXfk3TnRFRAhC3LGNLytzMieVIdP1aH6EA+92Rl6pgt60/xLSBdvbnBe4TD4k+55RiN70Gp4dmJAQznGocdahbOIeLSbhlurRkU0KOIEGdFb8fGPdM9IKoOpiUW5LkgTvr8REGEEAWLaNw/p0G+zlMh2z1InAS/fcdlF82ezzbltdMI15T7PfFZPtk1sGlfF3ye9qZfZMk4Po++B5whsrD17DxVosytYpQnT9saInamNfBmj11+zMvaa1oaoGDuFRFEia8k96P24ot2a1+u/rlxODhjH874 TtLaPv/y BfvhbDmuOpp+ZYG/L9+/XYoeNOV+1Afs60QIl6vMX7CeiXXXNFacuABKKhPhTjac6ptii9O6BqWbZczf+a4Bl+rmGx7aoCIP+Gx2NnDh/rmPO/Bg204GqY2mwUnrxg4XemAqvqTeCcUS8fAcYxSrJ+cMjdPpFgr0peoXYw7QjSWEjh3l4y7QlT86aQ+SmNJHnMyqYBYI5Bee2NeNJi/hDPLnzA5gmrtT61cPg4cpUwTI23ZDaY0tGDelV1H2MJ+aSFfS9IHAutARMZImpQ26auP9/qAjufJnqcko+ArFOPcoV6YvNels9I8za04sT0FhKMCYE3WJGRckk/xZf2qVmcPO8gszlDhzNfWB4gNyjVih9JCTr0mq18SUpW4Q+i1r8eTuSriSPs9fUVsm2gWFkQeSiCOW+LxCYLRuFvX/KOGDdNlqm7WFk8l74ajAuDsw9n28X6fue56eJQqWqFRxQqi38+UJWqeLLffuA 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: On Fri, Aug 18, 2023 at 11:44:45AM -0700, Yosry Ahmed wrote: > On Fri, Aug 18, 2023 at 11:35 AM Johannes Weiner wrote: > > > > On Fri, Aug 18, 2023 at 10:45:56AM -0700, Yosry Ahmed wrote: > > > On Fri, Aug 18, 2023 at 10:35 AM Johannes Weiner wrote: > > > > On Fri, Aug 18, 2023 at 07:56:37AM -0700, Yosry Ahmed wrote: > > > > > If this happens it seems possible for this to happen: > > > > > > > > > > cpu #1 cpu#2 > > > > > css_put() > > > > > /* css_free_rwork_fn is queued */ > > > > > rcu_read_lock() > > > > > mem_cgroup_from_id() > > > > > mem_cgroup_id_remove() > > > > > /* access memcg */ > > > > > > > > I don't quite see how that'd possible. IDR uses rcu_assign_pointer() > > > > during deletion, which inserts the necessary barriering. My > > > > understanding is that this should always be safe: > > > > > > > > rcu_read_lock() (writer serialization, in this case ref count == 0) > > > > foo = idr_find(x) idr_remove(x) > > > > if (foo) kfree_rcu(foo) > > > > LOAD(foo->bar) > > > > rcu_read_unlock() > > > > > > How does a barrier inside IDR removal protect against the memcg being > > > freed here though? > > > > > > If css_put() is executed out-of-order before mem_cgroup_id_remove(), > > > the memcg can be freed even before mem_cgroup_id_remove() is called, > > > right? > > > > css_put() can start earlier, but it's not allowed to reorder the rcu > > callback that frees past the rcu_assign_pointer() in idr_remove(). > > > > This is what RCU and its access primitives guarantees. It ensures that > > after "unpublishing" the pointer, all concurrent RCU-protected > > accesses to the object have finished, and the memory can be freed. > > I am not sure I understand, this is the scenario I mean: > > cpu#1 cpu#2 cpu#3 > css_put() > /* schedule free */ > rcu_read_lock() > idr_remove() > mem_cgroup_from_id() > > /* free memcg */ > /* use memcg */ idr_remove() cannot be re-ordered after scheduling the free. Think about it, this is the common rcu-freeing pattern: rcu_assign_pointer(p, NULL); call_rcu(rh, free_pointee); on the write side, and: rcu_read_lock(); pointee = rcu_dereference(p); if (pointee) do_stuff(pointee); rcu_read_unlock(); on the read side. In our case, the rcu_assign_pointer() is in idr_remove(). And the rcu_dereference() is in mem_cgroup_from_id() -> idr_find() -> radix_tree_lookup() -> radix_tree_descend(). So if we find the memcg in the idr under rcu lock, the cgroup rcu work is guaranteed to not run until the lock is dropped. If we don't find it, it may or may not have already run.