Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp836181ybz; Fri, 1 May 2020 09:23:11 -0700 (PDT) X-Google-Smtp-Source: APiQypJfVfs0EWko1aPfaZl0amus8wBo34dNyP0l0HtMRgtTTlYnH5nJa97WG0f4MD7CaIYGhCIf X-Received: by 2002:a05:6402:17c4:: with SMTP id s4mr4380543edy.348.1588350191205; Fri, 01 May 2020 09:23:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588350191; cv=none; d=google.com; s=arc-20160816; b=jaa+pT8uZgJnYHIb/KC0FDAOJdRltScGLdGZIeu/2IUxOVUPIrgcimO0BffVZJ14Jf lOoDkfdgapATtliMvHTH5/poUZj5xYgJ7/r+aGySzso4nWB/r0uJ6E9k282Gs8BOdxjT Nku2Y2onFz7ipM1UGUf81/JA6vGcfPtI3kjUMeTjEGaJ9sgT95GWCy3h4Y6sMYtiIIJb /dQ0pAoTIcrrtcHBiB7yRzotc7+Xw6qPi032gyHnIQ53eU/3C/XijXw1rAcWGFIFUzFu Qfu9IXotvpYS0rmUiiy2Dz0BqruBuMZeG5Bxz8EEIQObeBTumY24qQ6qB8EKTiRh6r13 k+Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=CzxbNDSQRZ559DkaCeQpN1wbLnv5bds6B3sF+bpkuz4=; b=D1IKIxIEqz6vCy7RtyqU/FGN0z4xjl0qHlLgqEc97uPRX6VfxVl1DxS0a1CHDLQihd zHMFUhWk6gJDdaYBOKU9oLQ8d4fCs3Aw9KA5Zhj8L0zEQ+w3KMYWtRnYE0Ggf1hr57Vw NgJvmdJILwpsQ9xuFddBOM9MyQO62z2q5Nvey9QnhSGX7Mv/sUAGA536CWmnCgfJ04kY arPziwEgdzx+BX33HzQCO+5Vqe95/c0+NwvUU8I+BhmjVRnE6X2b1NBwkpUCkJJoElud KL4C+LcKEHGGqcPm3/kWYYOwglHOZQIy1bN3rFxqsTWjMp6qaFAFve9wn7gUxI3zP+hi QEeg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ly8si2270296ejb.254.2020.05.01.09.22.48; Fri, 01 May 2020 09:23:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730028AbgEAQTT (ORCPT + 99 others); Fri, 1 May 2020 12:19:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:36792 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728495AbgEAQTS (ORCPT ); Fri, 1 May 2020 12:19:18 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ADC4E2166E; Fri, 1 May 2020 16:19:17 +0000 (UTC) Date: Fri, 1 May 2020 12:19:16 -0400 From: Steven Rostedt To: Josh Poimboeuf Cc: LKML , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Andy Lutomirski , Borislav Petkov , "H. Peter Anvin" Subject: Re: [RFC][PATCH] x86/ftrace: Have ftrace trampolines turn read-only at the end of system boot up Message-ID: <20200501121916.310942b8@gandalf.local.home> In-Reply-To: <20200501151310.zo5bhnxpu5gubofj@treble> References: <20200430202147.4dc6e2de@oasis.local.home> <20200501044733.eqf6hc6erucsd43x@treble> <20200501051706.4wkrqwovybt2p6hr@treble> <20200501092404.06d1adcb@gandalf.local.home> <20200501151310.zo5bhnxpu5gubofj@treble> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 1 May 2020 10:13:10 -0500 Josh Poimboeuf wrote: > On Fri, May 01, 2020 at 09:24:04AM -0400, Steven Rostedt wrote: > > On Fri, 1 May 2020 00:17:06 -0500 > > Josh Poimboeuf wrote: > > > > > > Would it be easier to just call a new __text_poke_bp() which skips the > > > > SYSTEM_BOOTING check, since you know the trampoline will always be > > > > read-only? > > > > > > > > Like: > > > > > > early_trace_init() is called after mm_init(), so I thought it might > > > work, but I guess not: > > > > Yeah, I was about to say that this happens before mm_init() ;-) > > It happens *after* mm_init(). But now text_poke() has a dependency on > poking_init(), has a dependency on proc_caches_init(), which has a > dependency on kmem_cache_init_late(), etc. > > So how early do you need early_trace_init()? I'm assuming moving it to > after kmem_cache_init_late() would be too late. People have asked to move it even earlier. The point of having it early is to allow tracing to debug early boot up. > > > It's why we already have magic for enabling function tracing the first time. > > > > Do you see anything wrong with this current solution? It probably needs > > more comments, but I wanted to get acceptance on the logic before I go and > > pretty it up and send a non RFC patch. > > Assuming we can't get text_poke() working earlier, it seems reasonable > to me. > Thanks. Peter, what about you? -- Steve