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.
