Thank you Johannes, Roman, and Yosry for reviewing this patch!
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.
On Thu, Jul 25, 2024 at 3:34 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote:
> On Thu, Jul 25, 2024 at 1:43 PM Johannes Weiner <hannes@xxxxxxxxxxx> 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.
> > 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).
> 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.