linux-kernel - Re: [tip:x86/idle] x86, idle: Use static_cpu_has() for CLFLUSH workaround, add barriers

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: <20131219204051.GA2253@gmail.com>
Date:	Thu, 19 Dec 2013 21:40:51 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	hpa@...or.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, peterz@...radead.org,
	tglx@...utronix.de, hpa@...ux.intel.com, len.brown@...el.com
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/idle] x86, idle: Use static_cpu_has() for CLFLUSH
 workaround, add barriers


* tip-bot for H. Peter Anvin <tipbot@...or.com> wrote:

> Commit-ID:  7e98b71920464b8d15fa95c74366416cd3c88861
> Gitweb:     http://git.kernel.org/tip/7e98b71920464b8d15fa95c74366416cd3c88861
> Author:     H. Peter Anvin <hpa@...ux.intel.com>
> AuthorDate: Thu, 19 Dec 2013 11:58:16 -0800
> Committer:  H. Peter Anvin <hpa@...ux.intel.com>
> CommitDate: Thu, 19 Dec 2013 11:58:16 -0800
> 
> x86, idle: Use static_cpu_has() for CLFLUSH workaround, add barriers
> 
> Use static_cpu_has() to conditionalize the CLFLUSH workaround, and add
> memory barriers around it since the documentation is explicit that
> CLFLUSH is only ordered with respect to MFENCE.
> 
> Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Len Brown <len.brown@...el.com>
> Link: http://lkml.kernel.org/r/CA%2B55aFzGxcML7j8CEvQPYzh0W81uVoAAVmGctMOUZ7CZ1yYd2A@mail.gmail.com
> ---
>  arch/x86/include/asm/mwait.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
> index 361b02e..19b71c4 100644
> --- a/arch/x86/include/asm/mwait.h
> +++ b/arch/x86/include/asm/mwait.h
> @@ -43,8 +43,11 @@ static inline void __mwait(unsigned long eax, unsigned long ecx)
>  static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
>  {
>  	if (!current_set_polling_and_test()) {
> -		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
> +		if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
> +			mb();
>  			clflush((void *)&current_thread_info()->flags);
> +			mb();
> +		}

So since this is a v3.14 commit, lets get it right, ok?

The first mb() looks superfluous, because see 
current_set_polling_and_test():

static inline bool __must_check current_set_polling_and_test(void)
{
        __current_set_polling();

        /*
         * Polling state must be visible before we test NEED_RESCHED,
         * paired by resched_task()
         */
        smp_mb();

        return unlikely(tif_need_resched());
}

So it already has a (MFENCE) barrier after ->flags is modified.

So using a comment - something like the patch below, should be enough 
as well, agreed?

Thanks,

	Ingo

Signed-off-by: Ingo Molnar <mingo@...nel.org>

diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
index 19b71c4..d4f5c9a 100644
--- a/arch/x86/include/asm/mwait.h
+++ b/arch/x86/include/asm/mwait.h
@@ -44,7 +44,10 @@ static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
 {
 	if (!current_set_polling_and_test()) {
 		if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
-			mb();
+			/*
+			 * There's no need for an extra barrier here: current_set_polling_and_test()
+			 * already has an smp_mb() after ->flags gets modified, see sched.h.
+			 */
 			clflush((void *)&current_thread_info()->flags);
 			mb();
 		}
--
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/