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 682F4C3DA5D for ; Thu, 25 Jul 2024 21:09:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B0486B0092; Thu, 25 Jul 2024 17:09:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9602D6B0093; Thu, 25 Jul 2024 17:09:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8281E6B0095; Thu, 25 Jul 2024 17:09:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 62D666B0092 for ; Thu, 25 Jul 2024 17:09:39 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F3BCA1214C2 for ; Thu, 25 Jul 2024 21:09:38 +0000 (UTC) X-FDA: 82379516436.15.2CB3AA9 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf08.hostedemail.com (Postfix) with ESMTP id 0CEFA16001D for ; Thu, 25 Jul 2024 21:09:35 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=aPmXhEtw; spf=pass (imf08.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721941727; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pCPuEvOfteQD+7e1yz6EqoVenBGR0CrTD60+z0NUItc=; b=kx+iYt18QKCdm5lyOW1blMsV+BpP4icOy2SXMZgyraPyoGhYkurA7ijmVfE5npcQrPQCjG gMWYid+NCkxC/V6qb5FX99RMKgClRNDDt3rMTS7kfz5R8oDQHb72UdbrviuV+3IEV8iEar p/HKYHvU6Z2t48ewaJiDnOa0K39L6ro= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721941727; a=rsa-sha256; cv=none; b=yrh7tr8iUUBeWTvjRCTM20cNRaKtrhnYxB0Ivz95JtQKgYacOt92DpjLy3DRzMkEMZdPX9 03OAkrDuJDx82i7LT3N4Oi+S5x8oET78QyvC/fRfNIReVvZswFTU/riI7PXWXuqqyUCCLw jjzjspQxUB8DsTw5uoKUkU6e0tJAhfs= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=aPmXhEtw; spf=pass (imf08.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 25 Jul 2024 21:09:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1721941773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pCPuEvOfteQD+7e1yz6EqoVenBGR0CrTD60+z0NUItc=; b=aPmXhEtwggljIX6OydnpC1U4iR61AvfVSPKPA4B/QtqT7wdT604LQFifUImkBLXy2sDYsk UFmidENcu2kPjny2RAYkiXO9vqlcg850YlJGQadzTmlfGysfnFi7ovCCAf+IF+DuLyQdw+ LTOtOqgClu6rXizs8HijFwta96N8xVI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Johannes Weiner Cc: Kinsey Ho , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yosry Ahmed Subject: Re: [PATCH mm-unstable v1 1/4] mm: don't hold css->refcnt during traversal Message-ID: References: <20240724190214.1108049-1-kinseyho@google.com> <20240724190214.1108049-2-kinseyho@google.com> <20240725204346.GA1702603@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240725204346.GA1702603@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0CEFA16001D X-Stat-Signature: jken8fa8cy3eqdk9wipq89jouygxouaf X-HE-Tag: 1721941775-600987 X-HE-Meta: U2FsdGVkX18qTQJVEMJAWUujT3KL0MnluxV33RdfsiuG+T1H3nC7H8wYG1b2s61aOmxMEew49qiz1K8iAm7Nt9eNbe+WiKvoZIKcGQEVaEqTonUoRJRMASGw5e6Tv4N+Vwg6/cACN8h6Er3g09I8LFBC87ZStr8et9y15jgrLHHEMof2bMu+k+LuoLwxQ+OlPv+uaMSSLiSnV7JwHpD/vVDpqJQL92u2PDSKV0x4C3IufCj1eVro2GvORO2RNzt0G3Ce3Jr7NqYkl2K+gYABn7h8vf9H8JHYwV8s7ta2P0DJoEpM6h4Kcgz7tB7Gx9MILZ59/6zxduWEyABZn6Zm9AfVlfUns1K1zyMosibQNIahZHBbM0y0e1IHIzJpAEtyB6dc+dI6UUNpgqKFeKVW7lI9PojlqeP1oYOogjl8qH8K6xWklzAjfqVIIYH1GbqgoVYpdZwFVryCT9wXM/Y4UaldklmXfjlTULNAhXl9CD4IdreATZjxH/CJ8qKUt/CeMkDC28KVbXM/a6CR6ZUCDtEl7nSpJBUd5lXAxy6URKbevzHop6C3BYOg2K8h8OPn2Dn5ogSWptItiikWe6SojwIBdsbuU3ypjkQi+E2fgbA6gwLcRC1x9V1c9UC+qt89P+SFugzKgz/GubdXot2WMUWmaPUVYcfi2VkOGfhvRUs8U5ePV7R2a2HL/Qt2qvKc3y8OJvK57FRclLTVux3xmUSj8Tg7eJDynjHUOg0KQlilIIA/iuLopYqeIqUumW1VoH75JcPMxlks/qdLD8DiB+NRLKNCGs5/vYG08pbzaIlAUkOC88vIiifFBI0SGnE5W3jAf5LUVTsjcJzw63QTp2A6howroh+XEq5DW3fC0yWcXzJ8wyQyqJm89g3ssQBcqbTRGLZRuZHGvhpsdj4eB80jeUMeoZDB1jURP8U/yfw1Hd4CkWnHkaufbX8UwOLWGpuePtHSpUegjP56nnR 6g0OPahF CzhjV1LOdA2gSlFY72K3/20RblFrNEgzLGwbJi32yvPWhNaHkTGBhXTSoMTPRZ+RU8brfF1PYCPL3yKBQ7fM8N+ZisZuEtiL4NwZgf6m+oVxFKboETKMCHF70v369icIs11E5O4bDM323gmd6vs/6vCtocA== 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: List-Subscribe: List-Unsubscribe: On Thu, Jul 25, 2024 at 04:43:46PM -0400, Johannes Weiner wrote: > On Wed, Jul 24, 2024 at 07:02:11PM +0000, Kinsey Ho wrote: > > To obtain the pointer to the saved memcg position, mem_cgroup_iter() > > currently holds css->refcnt during memcg traversal only to put > > css->refcnt at the end of the routine. This isn't necessary as an > > rcu_read_lock is already held throughout the function. > > > > Remove css->refcnt usage during traversal by leveraging RCU. > > Eh, I don't know about this. > > RCU ensures that the css memory isn't freed. > > The tryget ensures that the css is still alive and valid. > > In this case, it just so happens that the sibling linkage is also rcu > protected. But accessing random css members when the refcount is 0 is > kind of sketchy. On the other hand, the refcount is guaranteed to be > valid, and rcu + tryget is a common pattern. I also spent quite some time thinking about potential bad consequences, but _it seems_ to be safe (but I agree it feels dangerous). > > What does this buy us? The tryget is cheap. To be fair, tryget is not always cheap. Offline/dying cgroups have an atomic operation there.