[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1be951c7-442f-eb45-a4fc-41fdb771eef7@samsung.com>
Date: Wed, 9 Mar 2022 08:10:26 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Chengming Zhou <zhouchengming@...edance.com>, tj@...nel.org,
lizefan.x@...edance.com, hannes@...xchg.org, peterz@...radead.org
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
songmuchun@...edance.com,
Linux Kernel Functional Testing <lkft@...aro.org>,
syzbot+16e3f2c77e7c5a0113f9@...kaller.appspotmail.com,
Zhouyi Zhou <zhouzhouyi@...il.com>
Subject: Re: [PATCH linux-next] cgroup: fix suspicious
rcu_dereference_check() usage warning
On 05.03.2022 04:41, Chengming Zhou wrote:
> task_css_set_check() will use rcu_dereference_check() to check for
> rcu_read_lock_held() on the read-side, which is not true after commit
> dc6e0818bc9a ("sched/cpuacct: Optimize away RCU read lock"). This
> commit drop explicit rcu_read_lock(), change to RCU-sched read-side
> critical section. So fix the RCU warning by adding check for
> rcu_read_lock_sched_held().
>
> Fixes: dc6e0818bc9a ("sched/cpuacct: Optimize away RCU read lock")
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> Reported-by: syzbot+16e3f2c77e7c5a0113f9@...kaller.appspotmail.com
> Tested-by: Zhouyi Zhou <zhouzhouyi@...il.com>
> Signed-off-by: Chengming Zhou <zhouchengming@...edance.com>
Right, this fixes the issue I've reported here:
https://lore.kernel.org/all/f4bc652b-115f-35b5-91db-bad3b30fed9b@samsung.com/
Tested-by: Marek Szyprowski <m.szyprowski@...sung.com>
> ---
> include/linux/cgroup.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 1e356c222756..0d1ada8968d7 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -450,6 +450,7 @@ extern struct mutex cgroup_mutex;
> extern spinlock_t css_set_lock;
> #define task_css_set_check(task, __c) \
> rcu_dereference_check((task)->cgroups, \
> + rcu_read_lock_sched_held() || \
> lockdep_is_held(&cgroup_mutex) || \
> lockdep_is_held(&css_set_lock) || \
> ((task)->flags & PF_EXITING) || (__c))
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists