Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2427679pxp; Mon, 21 Mar 2022 20:07:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx362JTGj4vzLGuP1N9t+rhu+FrLTCzFNahnIDyrhePZCYg7Axwo2bBkjkEbfU3SoNkboor X-Received: by 2002:a05:6a00:190c:b0:4f7:e318:1a3f with SMTP id y12-20020a056a00190c00b004f7e3181a3fmr27054407pfi.43.1647918431013; Mon, 21 Mar 2022 20:07:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647918431; cv=none; d=google.com; s=arc-20160816; b=X9RQjszdyGuoUvwLehVCEyjRzEBab8eoq0RztI0JsgYPgWVC9clXkPvN7wMnvjygGX W64zRpS9CWjDBu2d9xa+73u9EL9WeDOMLYFn6Qn2CYgYm+ugGTY2zF682Po7fzd7KDby CzIfyrPwLzGnXKCLgsbqu3wyys8mrLlxHrA0XOYEIcE9cP1LShLrEHLJa2rpgrIgWayu WJkajkGRFL6yNtyQzjwAmBZeWgPzfsTFeIRdentYhzl94911U78sb8d1BHciUj1DlZYt 81y3+ze6vST8pkGcUsvuKodO76yGLMAGJC3oXt0dk+55SCmXfz8+0Nzi/LVJ0YHU6Igv rAQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:from:cc:content-transfer-encoding :mime-version:message-id:date:subject:dkim-signature; bh=kbDNC7nwvfxYUv1EhLiPssj97St0I3K9gZTYcVJqPsU=; b=PvfUfZxnYkR7nXi1LgSPigPm+rgnM0SHqgxx0VhqMB4kEE02V1cLny1Ek08q+Xryh8 bJOs3wEEA/9JplY7Z+loXDlv5qE7XfVn6XCJ5KwqdbRAS9Txh0l00D11iKrPwqAwPh0K 8IrMQOe78NUH3mJDqypGDK+cVxODDACM2uLuzfFaLVmqdY+AdaQL7n+s9OcLhUH6ru2v LA87p/3LIXclvjXWkwf//3xhpGvjT54ipipVwNQxrp70rbiWeIszfma8T2MHvQ+Dqq8N ksreZOGW5jPgvjEcLn6owsglwyXORQJBwtxNpJI6c13wOZXRZXUBINQFNf3m27HxUjyl Difw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b="7KoGB1p/"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id i27-20020a63131b000000b003817672f837si15081120pgl.21.2022.03.21.20.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 20:07:10 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b="7KoGB1p/"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 412BE24F02; Mon, 21 Mar 2022 19:40:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235538AbiCVClg (ORCPT + 99 others); Mon, 21 Mar 2022 22:41:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235438AbiCVCle (ORCPT ); Mon, 21 Mar 2022 22:41:34 -0400 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A0AA1FA45 for ; Mon, 21 Mar 2022 19:40:08 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id d76so2341283pga.8 for ; Mon, 21 Mar 2022 19:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=subject:date:message-id:mime-version:content-transfer-encoding:cc :from:to; bh=kbDNC7nwvfxYUv1EhLiPssj97St0I3K9gZTYcVJqPsU=; b=7KoGB1p/MFxA65A/e014UrzGVxM4M69YHYXwQNGOF7LAH6X+Lwbw6ayXRxuO0NBEKQ vLbIT7WLlrov+KxZ4afuppj3/cjqfqcF2gWKfCUMKQGzn0iTvwbhHbMAR9DGUQcgSXIp X92rooJ6q474av6j5dmRvm1KZVCtEko80yidm7jKmNuCaNezOiTqEw9qIeHd6C2at9yC ayfuigPqJD4CmcMGxBBR2v36eJJj6PrSWiZspGWQ5bmOUuHPthFirftTM+EVCA7HdzWM ligJjynIaI3bUbZmIji5CJg9UPkVAEDVBCDrl660O0gQH+PbaY4IM/Ru/WSn/OUJGzs5 QUtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:date:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=kbDNC7nwvfxYUv1EhLiPssj97St0I3K9gZTYcVJqPsU=; b=iQAILkX5MsVfwVnpilYSdi8Yo72yM/4mY4Uq8vwfw1mRaz6sgoF7vm5L+pfsp0rk1U +cGwUJBGMTqUtgKFujGJNPRgVEZHnZe6BRlY++HI5TUXb8Tdd35PiHTvwP8PTMmeexMk 6Dxc/7Y/9dGvJyp8BR6bYp32OQ6YKiZ3xNaMjTJPaRuxcoi7VFv/ujeizURQCCClEDFX 6CD4HKcDJOoW8g17lXYYqRiWqfNFPAs1K8jbRY5GFQlNkRtPUpvL6giekN3q3qF4lGB4 AxU3hrRM6FADmhe+iiGXyeqzniB7HKLJhVDcgj9E9EUdnqO0gOu3Ijkj7+OmGAn1ma6E JZyw== X-Gm-Message-State: AOAM530vglm+00Nr1CsVP5Sby6e9cr2rjFYSjkoFBzMoYRwz+Qah+86A nwphOfui/K6mAemUizalX+0mBPgZ1FdVxQ== X-Received: by 2002:a05:6a00:ad0:b0:4e1:2d96:2ab0 with SMTP id c16-20020a056a000ad000b004e12d962ab0mr27068856pfl.3.1647916807757; Mon, 21 Mar 2022 19:40:07 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id lj7-20020a17090b344700b001c7032eba5fsm724045pjb.4.2022.03.21.19.40.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 19:40:07 -0700 (PDT) Subject: [PATCH] RISC-V: Don't check text_mutex during stop_machine Date: Mon, 21 Mar 2022 19:23:31 -0700 Message-Id: <20220322022331.32136-1-palmer@rivosinc.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: mingo@redhat.com, Paul Walmsley , Palmer Dabbelt , aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Palmer Dabbelt , Palmer Dabbelt From: Palmer Dabbelt To: linux-riscv@lists.infradead.org, changbin.du@gmail.com, rostedt@goodmis.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Palmer Dabbelt We're currently using stop_machine() to update ftrace, which means that the thread that takes text_mutex during ftrace_prepare() may not be the same as the thread that eventually patches the code. This isn't actually a race because the lock is still held (preventing any other concurrent accesses) and there is only one thread running during stop_machine(), but it does trigger a lockdep failure. This patch just elides the lockdep check during stop_machine. Fixes: c15ac4fd60d5 ("riscv/ftrace: Add dynamic function tracer support") Suggested-by: Steven Rostedt Reported-by: Changbin Du Signed-off-by: Palmer Dabbelt Signed-off-by: Palmer Dabbelt -- Changes since v1 [<20210506071041.417854-1-palmer@dabbelt.com>]: * Use ftrace_arch_ocde_modify_{prepare,post_process}() to set the flag. I remember having a reason I wanted the function when I wrote the v1, but it's been almost a year and I forget what that was -- maybe I was just crazy, the patch was sent at midnight. * Fix DYNAMIC_FTRACE=n builds. --- arch/riscv/include/asm/ftrace.h | 7 +++++++ arch/riscv/kernel/ftrace.c | 12 ++++++++++++ arch/riscv/kernel/patch.c | 10 +++++++++- 3 files changed, 28 insertions(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h index 04dad3380041..3ac7609f4ee9 100644 --- a/arch/riscv/include/asm/ftrace.h +++ b/arch/riscv/include/asm/ftrace.h @@ -81,8 +81,15 @@ do { \ struct dyn_ftrace; int ftrace_init_nop(struct module *mod, struct dyn_ftrace *rec); #define ftrace_init_nop ftrace_init_nop +extern int riscv_ftrace_in_stop_machine; #endif +#else /* CONFIG_DYNAMIC_FTRACE */ + +#ifndef __ASSEMBLY__ +#define riscv_ftrace_in_stop_machine 0 #endif +#endif /* CONFIG_DYNAMIC_FTRACE */ + #endif /* _ASM_RISCV_FTRACE_H */ diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c index 4716f4cdc038..c5f77922d7ea 100644 --- a/arch/riscv/kernel/ftrace.c +++ b/arch/riscv/kernel/ftrace.c @@ -11,15 +11,27 @@ #include #include +int riscv_ftrace_in_stop_machine; + #ifdef CONFIG_DYNAMIC_FTRACE int ftrace_arch_code_modify_prepare(void) __acquires(&text_mutex) { mutex_lock(&text_mutex); + + /* + * The code sequences we use for ftrace can't be patched while the + * kernel is running, so we need to use stop_machine() to modify them + * for now. This doesn't play nice with text_mutex, we use this flag + * to elide the check. + */ + riscv_ftrace_in_stop_machine = true; + return 0; } int ftrace_arch_code_modify_post_process(void) __releases(&text_mutex) { + riscv_ftrace_in_stop_machine = false; mutex_unlock(&text_mutex); return 0; } diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c index 0b552873a577..7983dba477f0 100644 --- a/arch/riscv/kernel/patch.c +++ b/arch/riscv/kernel/patch.c @@ -11,6 +11,7 @@ #include #include #include +#include #include struct patch_insn { @@ -59,8 +60,15 @@ static int patch_insn_write(void *addr, const void *insn, size_t len) * Before reaching here, it was expected to lock the text_mutex * already, so we don't need to give another lock here and could * ensure that it was safe between each cores. + * + * We're currently using stop_machine() for ftrace, and while that + * ensures text_mutex is held before installing the mappings it does + * not ensure text_mutex is held by the calling thread. That's safe + * but triggers a lockdep failure, so just elide it for that specific + * case. */ - lockdep_assert_held(&text_mutex); + if (!riscv_ftrace_in_stop_machine) + lockdep_assert_held(&text_mutex); if (across_pages) patch_map(addr + len, FIX_TEXT_POKE1); -- 2.34.1