linux-kernel - Re: Use case for TASKS

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: <20170519100421.27298063@gandalf.local.home>
Date:   Fri, 19 May 2017 10:04:21 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Use case for TASKS_RCU

On Fri, 19 May 2017 06:35:50 -0700
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:

> Simpler would be better!
> 
> However, is it really guaranteed that one SCHED_IDLE thread cannot
> preempt another?  If not, then the trampoline-freeing SCHED_IDLE thread
> might preempt some other SCHED_IDLE thread in the middle of a trampoline.
> I am not seeing anything that prevents such preemption, but it is rather
> early local time, so I could easily be missing something.
> 
> However, if SCHED_IDLE threads cannot preempt other threads, even other
> SCHED_IDLE threads, then your approach sounds quite promising to me.
> 
> Steve, Peter, thoughts?

SCHED_IDLE is the swapper task. There's one on each CPU, and they don't
migrate. And they only get called when there's no other task running.

My worry is that if you have a busy CPU, then this will never finish,
as the idle task can be preempted forever. That would cause this to
never return:

  perf record -e ftrace:function sleep 1

That may never exit when it finishes, because the call to
unregister_ftrace_function() wont return till schedule_rcu_tasks()
returns. And worse yet, that is TASK_UNINTERRUPTIBLE state, where not
even a ctrl-C will stop it. It could possibly also trigger a hung task
warning.

-- Steve