Re: [PATCH] cgroup/cpuset: Fix "suspicious RCU usage" lockdep warning

[Phil Auld <pauld@redhat.com>]

On Wed, Feb 02, 2022 at 10:31:03PM -0500 Waiman Long wrote:
> It was found that a "suspicious RCU usage" lockdep warning was issued
> with the rcu_read_lock() call in update_sibling_cpumasks().  It is
> because the update_cpumasks_hier() function may sleep. So we have
> to release the RCU lock, call update_cpumasks_hier() and reacquire
> it afterward.
> 
> Also add a percpu_rwsem_assert_held() in update_sibling_cpumasks()
> instead of stating that in the comment.
> 
> Fixes: 4716909cc5c5 ("cpuset: Track cpusets that use parent's effective_cpus")
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
>  kernel/cgroup/cpuset.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index dc653ab26e50..b147acece984 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1522,10 +1522,15 @@ static void update_sibling_cpumasks(struct cpuset *parent, struct cpuset *cs,
>  	struct cpuset *sibling;
>  	struct cgroup_subsys_state *pos_css;
>  
> +	percpu_rwsem_assert_held(&cpuset_rwsem);
> +
>  	/*
>  	 * Check all its siblings and call update_cpumasks_hier()
>  	 * if their use_parent_ecpus flag is set in order for them
>  	 * to use the right effective_cpus value.
> +	 *
> +	 * The update_cpumasks_hier() function may sleep. So we have to
> +	 * release the RCU read lock before calling it.
>  	 */
>  	rcu_read_lock();
>  	cpuset_for_each_child(sibling, pos_css, parent) {
> @@ -1533,8 +1538,13 @@ static void update_sibling_cpumasks(struct cpuset *parent, struct cpuset *cs,
>  			continue;
>  		if (!sibling->use_parent_ecpus)
>  			continue;
> +		if (!css_tryget_online(&sibling->css))
> +			continue;
>  
> +		rcu_read_unlock();
>  		update_cpumasks_hier(sibling, tmp);
> +		rcu_read_lock();
> +		css_put(&sibling->css);
>  	}
>  	rcu_read_unlock();
>  }
> -- 
> 2.27.0
> 

This looks good. Thanks Waiman.

Tested-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Phil Auld <pauld@redhat.com>


Cheers,
Phil
--