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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BDD7C43219 for ; Tue, 30 Apr 2019 19:00:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 639472173E for ; Tue, 30 Apr 2019 19:00:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727234AbfD3TAS (ORCPT ); Tue, 30 Apr 2019 15:00:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:48614 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726112AbfD3TAR (ORCPT ); Tue, 30 Apr 2019 15:00:17 -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 27C7820854; Tue, 30 Apr 2019 19:00:14 +0000 (UTC) Date: Tue, 30 Apr 2019 15:00:12 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Andy Lutomirski , Peter Zijlstra , Nicolai Stange , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Shuah Khan , Konrad Rzeszutek Wilk , Tim Chen , Sebastian Andrzej Siewior , Mimi Zohar , Juergen Gross , Nick Desaulniers , Nayna Jain , Masahiro Yamada , Joerg Roedel , Linux List Kernel Mailing , live-patching@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" Subject: Re: [RFC][PATCH] ftrace/x86: Emulate call function while updating in breakpoint handler Message-ID: <20190430150012.58ed382b@gandalf.local.home> In-Reply-To: References: <20190428133826.3e142cfd@oasis.local.home> <20190430135602.GD2589@hirez.programming.kicks-ass.net> <20190430130359.330e895b@gandalf.local.home> <20190430132024.0f03f5b8@gandalf.local.home> <20190430134913.4e29ce72@gandalf.local.home> 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 Tue, 30 Apr 2019 11:33:21 -0700 Linus Torvalds wrote: > On Tue, Apr 30, 2019 at 10:49 AM Steven Rostedt wrote: > > > > + > > +asm( > > + ".text\n" > > + > > + /* Trampoline for function update with interrupts enabled */ > > + ".global ftrace_emulate_call_irqoff\n" > > + ".type ftrace_emulate_call_irqoff, @function\n" > > + "ftrace_emulate_call_irqoff:\n\t" > > + "push %gs:ftrace_bp_call_return\n\t" > > Well, as mentioned in my original suggestion, this won't work on > 32-bit, or on UP. They have different models for per-cpu data (32-bti > uses %fs, and UP doesn't use a segment override at all). Ah, yeah, I forgot about 32-bit. I could easily make this use fs as well, and for UP, just use a static variable. > > Maybe we just don't care about UP at all for this code, of course. > > And maybe we can make the decision to also make 32-bit just not use > this either - so maybe the code is ok per se, just needs to make sure > it never triggers for the cases that it's not written for.. > > > + "ftrace_emulate_call_update_irqoff:\n\t" > > + "push %gs:ftrace_bp_call_return\n\t" > > + "sti\n\t" > > + "jmp *ftrace_update_func_call\n" > > .. and this should then use the "push push sti ret" model instead. > > Plus get updated for objtool complaints. Yeah, I see that now. Somehow it disappeared when I looked for it after making some other changes. I can update it. > > Anyway, since Andy really likes the entry code change, can we have > that patch in parallel and judge the difference that way? Iirc, that > was x86-64 specific too. Note, I don't think live kernel patching supports 32 bit anyway, so that may not be an issue. Josh, When you come back to the office, can you look into that method? -- Steve