linux-kernel - Re: [PATCH 4/6] sched,idle: Clear polling before descheduling the idle thread

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: <20140604074416.GH30445@twins.programming.kicks-ass.net>
Date:	Wed, 4 Jun 2014 09:44:16 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	umgwanakikbuti@...il.com, mingo@...nel.org, tglx@...utronix.de,
	nicolas.pitre@...aro.org, daniel.lezcano@...aro.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] sched,idle: Clear polling before descheduling the
 idle thread

On Tue, Jun 03, 2014 at 05:29:50PM -0700, Andy Lutomirski wrote:
> Currently, the only real guarantee provided by the polling bit is
> that, if you hold rq->lock and the polling bit is set, then you can
> set need_resched to force a reschedule.
> 
> The only reason the lock is needed is that the idle thread might not
> be running at all when setting its need_resched bit, and rq->lock
> keeps it pinned.
> 
> This is easy to fix: just clear the polling bit before scheduling.
> Now the polling bit is only ever set when rq->curr == rq->idle.

Yah, except of course:

  lkml.kernel.org/r/20131120162736.508462614@...radead.org

which I really need to rebase and post again :/

In any case, this is useful even with that, although then we really must
do something like:

  rcu_read_lock();
  if (!set_nr_if_polling(rq->curr))
  	smp_send_reschedule(rq->cpu);
  rcu_read_unlock();

Because there's other tasks than rq->idle which might be 'idle', joy!

Content of type "application/pgp-signature" skipped