From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752816AbdHJQp5 (ORCPT ); Thu, 10 Aug 2017 12:45:57 -0400 Received: from terminus.zytor.com ([65.50.211.136]:37477 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751972AbdHJQp4 (ORCPT ); Thu, 10 Aug 2017 12:45:56 -0400 Date: Thu, 10 Aug 2017 09:42:12 -0700 From: tip-bot for Peter Zijlstra Message-ID: Cc: hpa@zytor.com, jkosina@suse.cz, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, rostedt@goodmis.org, mingo@kernel.org, tglx@linutronix.de, jpoimboe@redhat.com, peterz@infradead.org Reply-To: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, rostedt@goodmis.org, hpa@zytor.com, jkosina@suse.cz, mingo@kernel.org, tglx@linutronix.de, peterz@infradead.org, jpoimboe@redhat.com In-Reply-To: <20170731102154.f57cvkjtnbmtctk6@hirez.programming.kicks-ass.net> References: <20170731102154.f57cvkjtnbmtctk6@hirez.programming.kicks-ass.net> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/asm] x86: Clarify/fix no-op barriers for text_poke_bp() Git-Commit-ID: 01651324edad9db4fe49fb39b905c76861649b4c X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 01651324edad9db4fe49fb39b905c76861649b4c Gitweb: http://git.kernel.org/tip/01651324edad9db4fe49fb39b905c76861649b4c Author: Peter Zijlstra AuthorDate: Mon, 31 Jul 2017 12:21:54 +0200 Committer: Ingo Molnar CommitDate: Thu, 10 Aug 2017 17:35:19 +0200 x86: Clarify/fix no-op barriers for text_poke_bp() So I was looking at text_poke_bp() today and I couldn't make sense of the barriers there. How's for something like so? Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (VMware) Acked-by: Jiri Kosina Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: masami.hiramatsu.pt@hitachi.com Link: http://lkml.kernel.org/r/20170731102154.f57cvkjtnbmtctk6@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar --- arch/x86/kernel/alternative.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index 32e14d1..3344d33 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -742,7 +742,16 @@ static void *bp_int3_handler, *bp_int3_addr; int poke_int3_handler(struct pt_regs *regs) { - /* bp_patching_in_progress */ + /* + * Having observed our INT3 instruction, we now must observe + * bp_patching_in_progress. + * + * in_progress = TRUE INT3 + * WMB RMB + * write INT3 if (in_progress) + * + * Idem for bp_int3_handler. + */ smp_rmb(); if (likely(!bp_patching_in_progress)) @@ -788,9 +797,8 @@ void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler) bp_int3_addr = (u8 *)addr + sizeof(int3); bp_patching_in_progress = true; /* - * Corresponding read barrier in int3 notifier for - * making sure the in_progress flags is correctly ordered wrt. - * patching + * Corresponding read barrier in int3 notifier for making sure the + * in_progress and handler are correctly ordered wrt. patching. */ smp_wmb(); @@ -815,9 +823,11 @@ void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler) text_poke(addr, opcode, sizeof(int3)); on_each_cpu(do_sync_core, NULL, 1); - + /* + * sync_core() implies an smp_mb() and orders this store against + * the writing of the new instruction. + */ bp_patching_in_progress = false; - smp_wmb(); return addr; }