Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp8529imd; Fri, 2 Nov 2018 16:34:52 -0700 (PDT) X-Google-Smtp-Source: AJdET5d9oi47qjD0LvxUqCMIIbtt9zNhVSQWsRZGkmxcd5cX+QiR8lCT1c94NH59p73R2eHqElHr X-Received: by 2002:a63:ee0e:: with SMTP id e14mr12302668pgi.8.1541201692501; Fri, 02 Nov 2018 16:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541201692; cv=none; d=google.com; s=arc-20160816; b=ZwcTRUj2QywjylDeLh2M2tmmepWSaM36A2Pqq77/oyn+Wf1Xju/sViX9NuSOFA4MOU qx1c2EWm+csS5Ecchlwhqn2B7X8lHZwLXa4vUcubvcqLxX4ZTWVKEVKyD9hvB5I9fp7S 6ke5NEKXbMSTaRqtWrCOG18xRDwl0V4Ctlob3d/8KGwND8uxUqxwVo7ZCiISH129spO7 CKSSkZL4/uhE3vJn/9bsNlvHJS5BL/3ew/8v6hYUo9N0hAKVvzXP6pL2Y2VfQ9cZOpnQ nI8QwyVxMRPCDbXf9b96MB9z9YWbFLBzAzxFQIaxMyGZ7BcwIigYGy+yadePC8htASAO Ljzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=3AQ188Xz2SyWYYJj5U3jpy0FpexhaMvtm9oxT9Cko+0=; b=k9VeZ+VIm96ud113tF2rDB/muVnKspjj2YP67anh0agRRXC8hrAZ2+ZeB8SmlrJlLY CvlwH9HlUEFfWSTN9/4dCuJNfzGYbTM3wrpXCJr7XZkGghsaHsXZaPxH80RjMO9A0IfA RaN1uK47w4iq5dXG/XpGYEtcX+61HSlR50LuQO6Z0InuswYfP2ncbh/jvu7JyfXzfWi9 1zDz22XyywMcFLb6FBeBmhKeQhXqtPjbB8zT6lOHw7E8oop/skWjEQ3a9hPFsnGjMgwX fXE1Q0axWy+SkeH+fsFu8dc2hcUKOpAdZhRgdFxgL0YX4eyhcp18tSMuikuzlFd203J/ UYcA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si14259787pln.299.2018.11.02.16.34.38; Fri, 02 Nov 2018 16:34:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728513AbeKCIkz (ORCPT + 99 others); Sat, 3 Nov 2018 04:40:55 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:8611 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726877AbeKCIkz (ORCPT ); Sat, 3 Nov 2018 04:40:55 -0400 Received: from sc9-mailhost2.vmware.com (10.113.161.72) by EX13-EDG-OU-001.vmware.com (10.113.208.155) with Microsoft SMTP Server id 15.0.1156.6; Fri, 2 Nov 2018 16:31:32 -0700 Received: from sc2-haas01-esx0118.eng.vmware.com (sc2-haas01-esx0118.eng.vmware.com [10.172.44.118]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 8EA00B14C9; Fri, 2 Nov 2018 19:31:42 -0400 (EDT) From: Nadav Amit To: Ingo Molnar CC: , , "H. Peter Anvin" , Thomas Gleixner , Borislav Petkov , Dave Hansen , Nadav Amit , Jiri Kosina , Andy Lutomirski , Kees Cook , Dave Hansen Subject: [PATCH v3 1/7] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()" Date: Fri, 2 Nov 2018 16:29:40 -0700 Message-ID: <20181102232946.98461-2-namit@vmware.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181102232946.98461-1-namit@vmware.com> References: <20181102232946.98461-1-namit@vmware.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: None (EX13-EDG-OU-001.vmware.com: namit@vmware.com does not designate permitted sender hosts) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org text_mutex is expected to be held before text_poke() is called, but we cannot add a lockdep assertion since kgdb does not take it, and instead *supposedly* ensures the lock is not taken and will not be acquired by any other core while text_poke() is running. The reason for the "supposedly" comment is that it is not entirely clear that this would be the case if gdb_do_roundup is zero. Add a comment to clarify this behavior, and restore the assertions as they were before the recent commit. This partially reverts commit 9222f606506c ("x86/alternatives: Lockdep-enforce text_mutex in text_poke*()") Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Kees Cook Cc: Dave Hansen Fixes: 9222f606506c ("x86/alternatives: Lockdep-enforce text_mutex in text_poke*()") Reviewed-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Suggested-by: Peter Zijlstra Signed-off-by: Nadav Amit --- arch/x86/kernel/alternative.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index ebeac487a20c..1511d96d2e69 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -688,6 +688,11 @@ void *__init_or_module text_poke_early(void *addr, const void *opcode, * It means the size must be writable atomically and the address must be aligned * in a way that permits an atomic write. It also makes sure we fit on a single * page. + * + * Context: Must be called under text_mutex. kgdb is an exception: it does not + * hold the mutex, as it *supposedly* ensures that no other core is + * holding the mutex and ensures that none of them will acquire the + * mutex while the code runs. */ void *text_poke(void *addr, const void *opcode, size_t len) { @@ -702,8 +707,6 @@ void *text_poke(void *addr, const void *opcode, size_t len) */ BUG_ON(!after_bootmem); - lockdep_assert_held(&text_mutex); - if (!core_kernel_text((unsigned long)addr)) { pages[0] = vmalloc_to_page(addr); pages[1] = vmalloc_to_page(addr + PAGE_SIZE); -- 2.17.1