From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A148CECDFA1 for ; Tue, 25 Oct 2022 23:17:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232640AbiJYXRf (ORCPT ); Tue, 25 Oct 2022 19:17:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232602AbiJYXRc (ORCPT ); Tue, 25 Oct 2022 19:17:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4483E8C63 for ; Tue, 25 Oct 2022 16:17:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 841DD61BF8 for ; Tue, 25 Oct 2022 23:17:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E136C433D6; Tue, 25 Oct 2022 23:17:29 +0000 (UTC) Date: Tue, 25 Oct 2022 19:17:40 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Peter Zijlstra , dave.hansen@intel.com, linux-kernel@vger.kernel.org, x86@kernel.org, keescook@chromium.org, seanjc@google.com Subject: Re: [PATCH 0/5] x86/ftrace: Cure boot time W+X mapping Message-ID: <20221025191741.69a2196f@gandalf.local.home> In-Reply-To: References: <20221025200656.951281799@infradead.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 25 Oct 2022 16:07:25 -0700 Linus Torvalds wrote: > The slowness is probably not the trampilines, but just the regular > "text_poke of kernel text" that we probably want to keep special just > because otherwise it's _so_ slow to do for every alternative etc. Yes. That's why I recommended to change patch 4 to: if (unlikely(system_state == SYSTEM_BOOTING) && core_kernel_text((unsigned long)addr)) { text_poke_early(addr, opcode, len); return; } The only special case we had was the ftrace trampoline that was dynamically allocated, and there's paths that require updating it (when you add two function callbacks to the same location). -- Steve