linux-kernel - Re: [PATCH v5 4/5] sched/core: Prevent race condition between cpuset and __sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181108162348.GF18091@localhost.localdomain>
Date:   Thu, 8 Nov 2018 17:23:48 +0100
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Waiman Long <longman9394@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>, peterz@...radead.org,
        mingo@...hat.com, linux-kernel@...r.kernel.org,
        luca.abeni@...tannapisa.it, claudio@...dence.eu.com,
        tommaso.cucinotta@...tannapisa.it, bristot@...hat.com,
        mathieu.poirier@...aro.org, lizefan@...wei.com,
        cgroups@...r.kernel.org
Subject: Re: [PATCH v5 4/5] sched/core: Prevent race condition between cpuset
 and __sched_setscheduler()

Hi,

On 08/11/18 10:49, Waiman Long wrote:
> On 10/04/2018 05:04 AM, Juri Lelli wrote:

[...]

> > +/**
> > + * cpuset_read_only_lock - Grab the callback_lock from cpuset subsystem.
> > + *
> > + * Description: As described in full details the comment above cpuset_mutex
> > + * and callback_lock definitions, holding callback_lock gives the holder
> > + * read-only access to cpusets. Even though it might look counter-intuitive
> > + * (as callback_lock is a spinlock), in fact a task must hold both
> > + * callback_lock _and_ cpuset_mutex to modify cpusets (write access).
> > + */
> > +void cpuset_read_only_lock(void)
> > +{
> > +	raw_spin_lock(&callback_lock);
> > +}
> > +
> > +/**
> > + * cpuset_read_only_unlock - Release the callback_lock from cpuset subsystem.
> > + */
> > +void cpuset_read_only_unlock(void)
> > +{
> > +	raw_spin_unlock(&callback_lock);
> > +}
> > +
> 
> Maybe you can drop the "_only" part to be consistent with the rwlock
> APIs (read_lock/write_lock).

I called it this way because it looked more descriptive of which kind of
guarantee the holder gets using these. Can change of course, what others
think?

Thanks for reviewing!

Best,

- Juri