linux-kernel - Re: [PATCH] sched/rt: RT_RUNTIME

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]

Date:   Mon, 7 Nov 2016 13:30:15 -0600 (CST)
From:   Christoph Lameter <cl@...ux.com>
To:     Steven Rostedt <rostedt@...dmis.org>
cc:     Daniel Bristot de Oliveira <bristot@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016, Steven Rostedt wrote:

> On Mon, 7 Nov 2016 10:55:38 -0600 (CST)
> Christoph Lameter <cl@...ux.com> wrote:
>
> > On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote:
> >
> > > With these two options set, the user will guarantee some runtime
> > > for non-rt-tasks on all CPUs, while keeping real-time tasks running
> > > as much as possible.
> >
> > Excellent this would improve the situation with deadlocks as a result of
> > cgroup_locks not being released due to lack of workqueue processing.
>
> ?? What deadlocks do you see? I mean, can you show the situation that
> throttling RT tasks will cause deadlock?
>
> Sorry, but I'm just not seeing it.

SCHED_RR tasks alternately running on on cpu can cause endless deferral of
kworker threads. With the global effect of the OS processing reserved
it may be the case that the processor we are executing never gets any
time. And if that kworker threads role is releasing a mutex (like the
cgroup_lock) then deadlocks can result.