linux-kernel - Re: [PATCH mm-unstable v1 1/4] mm: don't hold css->refcnt during traversal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240725204346.GA1702603@cmpxchg.org>
Date: Thu, 25 Jul 2024 16:43:46 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Kinsey Ho <kinseyho@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Yosry Ahmed <yosryahmed@...gle.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>
Subject: Re: [PATCH mm-unstable v1 1/4] mm: don't hold css->refcnt during
 traversal

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.

What does this buy us? The tryget is cheap.