Re: [PATCH v2 2/8] sched/topology: Wrappers for sched_domains_mutex

[Waiman Long <llong@redhat.com>]

On 3/7/25 10:59 AM, Juri Lelli wrote:
> On 07/03/25 10:19, Waiman Long wrote:
>> On 3/7/25 10:11 AM, Waiman Long wrote:
>>> On 3/6/25 9:10 AM, Juri Lelli wrote:
>>>> Create wrappers for sched_domains_mutex so that it can transparently be
>>>> used on both CONFIG_SMP and !CONFIG_SMP, as some function will need to
>>>> do.
>>>>
>>>> Reported-by: Jon Hunter <jonathanh@nvidia.com>
>>>> Fixes: 53916d5fd3c0 ("sched/deadline: Check bandwidth overflow
>>>> earlier for hotplug")
>>>> Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
>>>> ---
>>>> v1 -> v2: Remove wrappers for the !SMP case as all users are not defined
>>>>             either in that case
>>>> ---
>>>>    include/linux/sched.h   |  2 ++
>>>>    kernel/cgroup/cpuset.c  |  4 ++--
>>>>    kernel/sched/core.c     |  4 ++--
>>>>    kernel/sched/debug.c    |  8 ++++----
>>>>    kernel/sched/topology.c | 12 ++++++++++--
>>>>    5 files changed, 20 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>>> index 9632e3318e0d..d5f8c161d852 100644
>>>> --- a/include/linux/sched.h
>>>> +++ b/include/linux/sched.h
>>>> @@ -383,6 +383,8 @@ enum uclamp_id {
>>>>    extern struct root_domain def_root_domain;
>>>>    extern struct mutex sched_domains_mutex;
>>>>    #endif
>>>> +extern void sched_domains_mutex_lock(void);
>>>> +extern void sched_domains_mutex_unlock(void);
>>> As discussed in the other thread, move the
>>> sched_domains_mutex_{lock/unlock}{} inside the "#if CONFIG_SMP" block
>>> and define the else part so that it can be used in code block that will
>>> also be compiled in the !CONFIG_SMP case.
>>>
>>> Other than that, the rest looks good to me.
>> Actually, you can also remove sched_domains_mutex from the header and make
>> it static as it is no longer directly accessed.
> Apart from a lockdep_assert_held() in cpuset.c, no? Guess I can create a
> wrapper for that, but is it really better?

I forgot about that. Please ignore this comment.

Thanks,
Longman