lkml.org 
[lkml]   [2023]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 2/6] sched/cpuset: Bring back cpuset_mutex
    On Wed, May 03, 2023 at 09:22:24AM +0200, Juri Lelli wrote:

    > /*
    > - * There are two global locks guarding cpuset structures - cpuset_rwsem and
    > + * 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_rwsem write lock. Other
    > - * kernel subsystems can use cpuset_read_lock()/cpuset_read_unlock() to
    > - * prevent change to cpuset structures.
    > + * comment. The cpuset code uses only cpuset_mutex. Other kernel subsystems
    > + * can use cpuset_lock()/cpuset_unlock() to prevent change to cpuset
    > + * structures.
    > *
    > * A task must hold both locks to modify cpusets. If a task holds
    > - * cpuset_rwsem, it blocks others wanting that rwsem, ensuring that it
    > - * is the only task able to also acquire callback_lock and be able to
    > - * modify cpusets. It can perform various checks on the cpuset structure
    > - * first, knowing nothing will change. It can also allocate memory while
    > - * just holding cpuset_rwsem. While it is performing these checks, various
    > - * callback routines can briefly acquire callback_lock to query cpusets.
    > - * Once it is ready to make the changes, it takes callback_lock, blocking
    > - * everyone else.
    > + * cpuset_mutex, it blocks others, ensuring that it is the only task able to
    > + * also acquire callback_lock and be able to modify cpusets. It can perform
    > + * various checks on the cpuset structure first, knowing nothing will change.
    > + * It can also allocate memory while just holding cpuset_mutex. While it is
    > + * performing these checks, various callback routines can briefly acquire
    > + * callback_lock to query cpusets. Once it is ready to make the changes, it
    > + * takes callback_lock, blocking everyone else.
    > *
    > * Calls to the kernel memory allocator can not be made while holding
    > * callback_lock, as that would risk double tripping on callback_lock
    > @@ -403,16 +402,16 @@ static struct cpuset top_cpuset = {
    > * guidelines for accessing subsystem state in kernel/cgroup.c
    > */
    >
    > -DEFINE_STATIC_PERCPU_RWSEM(cpuset_rwsem);
    > +static DEFINE_MUTEX(cpuset_mutex);

    Perhaps extend the comment to state you explicitly want a mutex for PI
    etc.. ?

    \
     
     \ /
      Last update: 2023-05-04 08:20    [W:2.987 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site