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 068DAEE498D for ; Fri, 18 Aug 2023 18:45:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81BFA94006C; Fri, 18 Aug 2023 14:45:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A5C2940012; Fri, 18 Aug 2023 14:45:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6450E94006C; Fri, 18 Aug 2023 14:45:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5137E940012 for ; Fri, 18 Aug 2023 14:45:25 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1BDD080CBA for ; Fri, 18 Aug 2023 18:45:25 +0000 (UTC) X-FDA: 81138103410.18.00B5ACA Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf17.hostedemail.com (Postfix) with ESMTP id 383E340024 for ; Fri, 18 Aug 2023 18:45:22 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=vAtdehoo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692384323; 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=/OpUekKOL7rOGJBNxIgNqZBQH13Oof9rm7gx23Q+vF4=; b=bjYZEvwE2Fbh9MXxjSnz/nfBUHO8TvseU2QHzuX2vmI6a2Az4W1CHubzCwlIuIuaLI2Ihf 9iBIHYAwbF8d+32FWVZUyF4UUXLIaxkyInZcvRf4V6WIRHxBGhP0x2TvCZDKWfiifXOtfD BrNInV9IBfeSvzgFbWdC/P30k2oS1ZY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=vAtdehoo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692384323; a=rsa-sha256; cv=none; b=4ZpB3Qa2N8KCDoqs9ECCVKyA9fdMoNlc3BTMgbAnpvTE1I+DQop+5mukNqKjL7gpF4RqyV M3r3N2TIIj1fFGZBT4y9Ti8Os8k3MsXhMwYqtkxChkUN50i/QcpgXXBdtGijhfuiHO6Ino m8qqar0jh+Fj9ILVpNhJzHNVRMA+QkU= Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-99bfcf4c814so159867066b.0 for ; Fri, 18 Aug 2023 11:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692384321; x=1692989121; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/OpUekKOL7rOGJBNxIgNqZBQH13Oof9rm7gx23Q+vF4=; b=vAtdehoo6I1lNDfKtGjfJ2iOzLF6DdcbLIcdAKZ8+RkfdVvn4HZ/Vhnpki/108TxY7 kxwae7K/6Hytn1y8Ki91/O2GxRrCIObiWNevq3T9x2fSWGiYR7iv8R5lq/xA4yQ86AS8 VCmNojROLDE5J10pueU5PZCnjQ5oy5OwpNBsGivqR+Ro0KhJSlJ+LD5GedL5YFpT1zTN jnT3JwNfCP3icLVhBX8SR6qZf9I0RKDgnLIYG3JjT0VQ+nK4gXzmNICcy/eWN8ztbdrC kV6tVyPbcC0V3zmm0JA8auObj+YUcDmJ3DgtL5LSB42WZT3fCIc2eXEA4XKxzNEvSHfJ zz+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692384321; x=1692989121; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/OpUekKOL7rOGJBNxIgNqZBQH13Oof9rm7gx23Q+vF4=; b=GaoXryT+jV6i1mT74gQlWDfW+EYDRX0XAuk28CPtm8RfSRWBnKNLPPpDlivqpvYz3Z wvr/QWTsws9tDgSWxpSaGX+w5l95bZCvOtoMYjuB8PQk9ZUctxnNQsKtbDHrfgomoosQ RFKMbiDl6jcdQlO5MxOenIt71Qa08/x8T2IVYlDcTqzS1KwFJQfYKL+/82ALNG0JnZDW tKKh9H/oZWr1YY1JBqJ+vALNFsDn4E7TLtSj+34J7mxpjQ6IU3VaH6Q7CFxfE//OBs+J a4fkz8ycqpnnp297v34g1T515qcafmGz9WJuVFIyHIGLsLhifk6QwXLtGTh0R2RDycJi NIUw== X-Gm-Message-State: AOJu0Ywd28Ik9yZzz9Py2FX+EhMm+gsewdqqu0mU+Ov3/529wyBdphnU bPwx4aupff7Vi4fcwBgg+Gghy08J3qeJNL2laB13hw== X-Google-Smtp-Source: AGHT+IHaz+eU/4XGr2yCar2iH/zFlNy9/NYOsV48aXfqt/tGUveLEC/av4PLRa4fnixBg/BFFsPFYfrxUuk43eVAa3M= X-Received: by 2002:a17:906:3018:b0:99e:6a0:5f64 with SMTP id 24-20020a170906301800b0099e06a05f64mr32393ejz.36.1692384321374; Fri, 18 Aug 2023 11:45:21 -0700 (PDT) MIME-Version: 1.0 References: <20230817164733.2475092-1-nphamcs@gmail.com> <20230817190126.3155299-1-nphamcs@gmail.com> <20230818134906.GA138967@cmpxchg.org> <20230818173544.GA142196@cmpxchg.org> <20230818183538.GA142974@cmpxchg.org> In-Reply-To: <20230818183538.GA142974@cmpxchg.org> From: Yosry Ahmed Date: Fri, 18 Aug 2023 11:44:45 -0700 Message-ID: Subject: Re: [PATCH v2] workingset: ensure memcg is valid for recency check To: Johannes Weiner 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 383E340024 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: gbtycqr117azzahq6w6uawxy6raeo5jm X-HE-Tag: 1692384322-20200 X-HE-Meta: U2FsdGVkX19o+RqjtHWlPH6/uD6FEPbcH5gjGzhTXJsOfJsK0SOcxF6mln/ly0YjgK5xNvuGTmNBtFCvWi/h1c1tcUDSwgOX7dh/6S1VI4oqcuiuGPimY8JMCrtnTT8/8qzWuAMTSNVIGb32UdbVELMb1E29xW5QSdMSYl0zAkvYscsRBA+I7fZUJ2imU3fTPM6x9GTSRj/YtKgw4qv+Gw5KpUAor3nXZ8dAb9bCwWBlqAzAm6wG37yTUK+gOykore8x6ARQ9b4uFmt0zQEuQacu+x7ets30lSttpL2M3lc/q8QjvDfThAw4gVHPjaU+gUD0h8xZjFmHY0Qnsu2SwMJ8CQ8LIcWt8fnIZdj9DK3gP2HMdOL37ncpIsHc313FfgmnLTmX/3hdG6jDiosboj8ws5Dt33veMuvQbppRvOw1MdgZYUFVyPv5eLYCJ0ajli5QpHPBEtvie6/TVRjQnUuLlQUaVDmy9Uo4P0P+soI7WE2H5WudBBuzxfnaBHALjKW+X13UzECGc4e8smnXwi+HQwd7VdgXv9cObMc5KjrwNch+l3buwk8X2jPyGz16n++S2jdnr5M6KUA2pgmRDywMWZ+783HuanivlD5KdoKWVD7SnjeM0MJ4Hs+N9aTxt3xMoLiMQebIG20OxgZSng6by3nFf+c7D+iGc1hA7avuVgygKvuueyfeD7ZYz8xvu90uzZX6pqmLSElwCjeI7CLkd9Ft1oYhOMAcWYxlEwDSC2xT9eximHEuG27t2SCRguJkMaZ559gKxbl0gnR6fnGv/vz5nFtBYBQONe+t3EgaQzYcVC7Hq3OltV/cFyarJ+9XEnDjSX9dbCf7vNr1JvL4hdUp/sIzW+mxbfUormgf4DLiVfhI5Sa+Si801G7x46ZtqR+seMN092OQEy5DpFowqDKcc4yZP7K0Hw5I/jq4LSHR1IbdX3Hzx33eWh+Xq4MLlCfdnC9F0+Y4eWl WjYMfZht R7RK9DVFMWYDKFsTikXUJCYoj3UWkpwPTqxNPlhXkSU5bx0c/LHWu6n/Wq+g9KWtWKTbLT2Nk3czOKP5FRYMhXZfQBun6EauVOWLg18fE3SERpdC+6ov4gfVJiu3unBBkpfUfwHWQmQAuIp0mHBfQlvuu7ZWjTkREhe5QTEbRdxq5+QnX/iSv+BUEZHVXo4y3gqi/Ba3MXa9vcCwhkiVYoQgYFwnFtJdSK2A9GQhKhOexnKt5SzVhT++a+NpozWwBrA3oIgajQK45+j6Zsu7ZWd13l8IO1vydEuAD 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:35=E2=80=AFAM Johannes Weiner wrote: > > On Fri, Aug 18, 2023 at 10:45:56AM -0700, Yosry Ahmed wrote: > > On Fri, Aug 18, 2023 at 10:35=E2=80=AFAM 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 i= s 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 =3D=3D 0) > > > foo =3D 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 */ If I understand correctly you are saying that the scheduled free callback cannot run before idr_remove() due to the barrier in there, but it can run after the rcu_read_lock() in cpu #2 because it was scheduled before that RCU critical section started, right?