[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF6N3nW5ZwE_e7bF3eZqiD6d_QhkCyzZM4DEgo74kgO=hVU2Nw@mail.gmail.com>
Date: Thu, 1 Aug 2024 15:32:53 -0700
From: Kinsey Ho <kinseyho@...gle.com>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: Johannes Weiner <hannes@...xchg.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Roman Gushchin <roman.gushchin@...ux.dev>
Subject: Re: [PATCH mm-unstable v1 1/4] mm: don't hold css->refcnt during traversal
Sorry, I replied to this email earlier but it had some issues with plain
text. Please ignore the first reply of mine (the one with HTML). I'm resending
the email below.
Thank you Johannes, Roman, and Yosry for reviewing this patch!
On Thu, Jul 25, 2024 at 3:34 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
> On Thu, Jul 25, 2024 at 1:43 PM Johannes Weiner <hannes@...xchg.org> wrote:
> > What does this buy us? The tryget is cheap.
>
> mem_cgroup_iter() is not an easy function to follow, so I personally
> appreciate the simplicity gains tbh.
Yes, the main intention here was to simplify the code's readability.
> This reads to me like it is intentional that RCU protection is enough
> for @pos and @root, and that the sibling linkage is RCU protected by
> design. Perhaps we could clarify this further (whether at
> css_next_descendant_pre(), or above the definition of the linkage
> members).
Do we want to move forward with Yosry's suggestion to clarify that the
sibling linkage is RCU-protected by design? Perhaps this clarification
can be made in the definition of the linkage members so that the
safety of the css in this function is more clear to users. If this is
sufficient, I will make the change in a v2 patchset.
Powered by blists - more mailing lists