linux-kernel - Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20170407071323.GA5360@gmail.com>
Date:   Fri, 7 Apr 2017 09:13:23 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>
Subject: Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU
 mask


* Thomas Gleixner <tglx@...utronix.de> wrote:

> On Thu, 6 Apr 2017, Ingo Molnar wrote:
> > CPU hotplug and changing the affinity mask are the more complex cases, because 
> > there migrating or not migrating is a correctness issue:
> > 
> >  - CPU hotplug has to be aware of this anyway, regardless of whether it's solved 
> >    via a counter of the affinity mask.
> 
> You have to prevent CPU hotplug simply as long as there are migration disabled 
> tasks on the fly. Making that depend on whether they are on a CPU which is about 
> to be unplugged or not would be complete overkill as you still have to solve the 
> case that a task sets the migrate_disable() AFTER the cpu down machinery 
> started.
>
> [...]
>
> The counter alone might be enough for the scheduler placement decisions, but it 
> cannot solve the hotplug issue. You still need something like I sketched out in 
> my previous reply.

Yes, so what you outlined:

void migrate_disable(void)
{
        if (in_atomic() || irqs_disabled())
                return;

        if (!current->migration_disabled) {
                percpu_down_read_preempt_disable(hotplug_rwsem);
                current->migration_disabled++;
                preempt_enable();
        } else {
                current->migration_disabled++;
        }
}

Would solve it?

I.e. my point is: whether migrate_disable()/enable() is implemented via a counter 
or a pointer to a cpumask does not materially change how the CPU-hotplug solution 
looks like, right?

I.e. we could just use the counter and avoid the whole wrapping of cpumask 
complexity.

Thanks,

	Ingo