[PATCH] cgroup/cpuset: Remove stale text

[PATCH] cgroup/cpuset: Remove stale text

[Costa Shulyupin]

Paragraph "The task_lock() exception ...." was removed by
commit 2df167a300d7 ("cgroups: update comments in cpuset.c")

Remove stale text:
'See "The task_lock() exception", at the end of this comment.'
and reformat.

Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
 kernel/cgroup/cpuset.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index d5d2b4036314..c833a86f73ce 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -208,9 +208,8 @@ static struct cpuset top_cpuset = {
 /*
  * There are two global locks guarding cpuset structures - cpuset_mutex and
  * callback_lock. We also require taking task_lock() when dereferencing a
- * task's cpuset pointer. See "The task_lock() exception", at the end of this
- * comment.  The cpuset code uses only cpuset_mutex. Other kernel subsystems
- * can use cpuset_lock()/cpuset_unlock() to prevent change to cpuset
+ * task's cpuset pointer.  The cpuset code uses only cpuset_mutex. Other kernel
+ * subsystems can use cpuset_lock()/cpuset_unlock() to prevent change to cpuset
  * structures. Note that cpuset_mutex needs to be a mutex as it is used in
  * paths that rely on priority inheritance (e.g. scheduler - on RT) for
  * correctness.
-- 
2.47.0

Re: [PATCH] cgroup/cpuset: Remove stale text

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

Hello.

On Tue, Dec 03, 2024 at 11:54:13AM GMT, Costa Shulyupin <costa.shul@redhat.com> wrote:
> Remove stale text:
> 'See "The task_lock() exception", at the end of this comment.'
> and reformat.

It seems you've read through the comments recently.
Do you have more up your sleeve? (It could be lumped together.)
Unless it was an accidental catch.

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] cgroup/cpuset: Remove stale text

[Costa Shulyupin]

Does
"Accessing a task's cpuset should be done in accordance with the
guidelines for accessing subsystem state in kernel/cgroup.c"
means `css_set_lock` defined in kernel/cgroup/cpuset.c (moved from
kernel/cgroup.c)

Are mentioned guidelines now in include/linux/cgroup-defs.h?

Thanks
Costa

On Tue, 3 Dec 2024 at 14:31, Michal Koutný <mkoutny@suse.com> wrote:
>
> Hello.
>
> On Tue, Dec 03, 2024 at 11:54:13AM GMT, Costa Shulyupin <costa.shul@redhat.com> wrote:
> > Remove stale text:
> > 'See "The task_lock() exception", at the end of this comment.'
> > and reformat.
>
> It seems you've read through the comments recently.
> Do you have more up your sleeve? (It could be lumped together.)
> Unless it was an accidental catch.
>
> Thanks,
> Michal

Re: [PATCH] cgroup/cpuset: Remove stale text

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Tue, Dec 03, 2024 at 10:43:26AM GMT, Waiman Long <llong@redhat.com> wrote:
> Thank for noticing the stale comment. There is actually no task's cpuset
> pointer anymore.

Yeah, that likely evolved into task_struct.cgroup css_set pointer. The
"guidelines" for it are in sched.h/task_struct comments + comments for
struct cgroup_subsys_state.
Also, users may need css_get()/css_put() if they needs subsys state for
longer. (This info isn't actually cpuset specific.)

HTH,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] cgroup/cpuset: Remove stale text

[Waiman Long]

On 12/3/24 12:21 PM, Michal Koutný wrote:
> On Tue, Dec 03, 2024 at 10:43:26AM GMT, Waiman Long <llong@redhat.com> wrote:
>> Thank for noticing the stale comment. There is actually no task's cpuset
>> pointer anymore.
> Yeah, that likely evolved into task_struct.cgroup css_set pointer. The
> "guidelines" for it are in sched.h/task_struct comments + comments for
> struct cgroup_subsys_state.
> Also, users may need css_get()/css_put() if they needs subsys state for
> longer. (This info isn't actually cpuset specific.)

Yes, that is likely the case though I didn't trace back the git log to 
figure out its exact evolution. Anyway, these information are optional 
as it is not cpuset specific.

Cheers,
Longman