linux-kernel - Re: [tip:x86/asm] x86: Speed up ___preempt

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:	Fri, 3 Oct 2014 17:01:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>, Peter Anvin <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...capital.net>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Chuck Ebbert <cebbert.lkml@...il.com>
Subject: Re: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers

On Fri, Oct 3, 2014 at 4:26 PM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> And I _think_ that preempt_schedule_context() should be fixed anyway,
> although I am not sure there is no something else. It does:
>
>
>         preempt_disable_notrace();
>         prev_ctx = exception_enter();
>         preempt_enable_no_resched_notrace();
>
>         preempt_schedule();
>
>         preempt_disable_notrace();
>         exception_exit(prev_ctx);
>         preempt_enable_notrace();
>
> but exception_exit() is heavy, it is quite possible that TIF_NEED_RESCHED
> and thus set_preempt_need_resched() can be set again when we call
> preempt_enable_notrace(). And in this case preempt_schedule_context()
> will be called recursively.

Why the hell is it using "preempt_enable_notrace()" in the first
place? Shouldn't it use "preempt_enable_no_resched_notrace()", since
we do *not* want it to schedule, since the whole *point* is that any
scheduling should be called within "exception" context.

> Frederic, how about the patch below?

Why do it multiple times? The whole concept is fundamentally racy
anyway, in it doesn't guarantee that any *new* "need_resched()" would
be reacted to (since they could happen *after* the test), so there's
no point in trying to fix the "race", since it always remains at the
last iteration anyway.  So adding the loop looks like just voodoo
programming, not actually fixing anything.

The real fix would appear to be to use
"preempt_enable_no_resched_notrace()", which your patch did, but
without the loop.

Yes?

             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/