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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4F978C433EF for ; Wed, 2 Feb 2022 06:12:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To: Message-Id:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=e7bq/d4bt9V5p0pNuJ7u2SVJ/4rjtJsmgdGkSAPrvho=; b=jBx8wn0gpfYGOe DbmEqXk6vTC5JASvR13XD8bcaoAlufADu/6dGCJ4hADMsLtpINC5k9j2G34fZIyqKAeaBm0ky4tDs YWCRTKvdCYgnbrlOPe54og/NUOn5WyF1RpuoJy2yyHWfZEHN8M1njrfAWM5SEg6mXx/DjuxtUJLmK VJK1A+aiM0l1NipqRr49lwRI9IJTf7yK+85nW+0BTZiqxePsB5b22o1b6JmVBcaO9oEcG8TXJDlgr 1AqZbfEOunI1/LNJ+6dZ1XY9wVtreJxa+aSejSsEp5NHeHyKRQYW26wRikx//L2rPNcCxHc1MEgcI LyKxw+32w0sxP1PTe3eQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nF8qq-00EGxL-98; Wed, 02 Feb 2022 06:10:44 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nF8qm-00EGwn-1N for linux-arm-kernel@lists.infradead.org; Wed, 02 Feb 2022 06:10:41 +0000 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 912A961731; Wed, 2 Feb 2022 06:10:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C5DDC004E1; Wed, 2 Feb 2022 06:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643782239; bh=cvq9NQPZ0ovgQtJWXSJf2yVaOzxK3p9SfT+HJGil0R8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aEnco0WRmM9Z/lT8dSO7Vwa1zvuSTzIrFuOK056hkVdEGH/B6dlx7hvvlewqV7/ZQ Fj4KNFxWlXgGFbni2q1x3iT3Mzd7/ylA8GgVW0n18v/d3qQstcTVXSt1z4Tz5+eWYk HpMpnZuQGJERpLU2def/UEatPKBjNmq6NcD6PCL6sLb4MB4wDPINmB63/HaKWhZ+Bj mfbr84z0MwwMMIvO0p68cRz4hBxJNv2URiTYggdWvVz32zu4velJHRllICFy6+XqmW rFFqJ7PEJ8e1I4zpXu2JZlBA+L88a5/NNe5jDNHsHAl6c0ug3oC3xSse3Cl3rCG/ML qrsdRyibN+GSA== Date: Wed, 2 Feb 2022 15:10:33 +0900 From: Masami Hiramatsu To: Ard Biesheuvel Cc: Russell King , Linux ARM , Steven Rostedt , Sudeep Holla , Cristian Marussi , Nathan Chancellor , Nick Desaulniers , Arnd Bergmann , Linus Walleij Subject: Re: [PATCH v2 09/12] ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds Message-Id: <20220202151033.ebe29e1256d19781ffc87ca3@kernel.org> In-Reply-To: References: <20220131170347.381551-1-ardb@kernel.org> <20220131170347.381551-10-ardb@kernel.org> <20220201221839.2617126c5b19ca4caafe2851@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220201_221040_164955_DC9170C6 X-CRM114-Status: GOOD ( 30.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 1 Feb 2022 15:05:25 +0100 Ard Biesheuvel wrote: > On Tue, 1 Feb 2022 at 14:18, Masami Hiramatsu wrote: > > > > On Mon, 31 Jan 2022 18:03:44 +0100 > > Ard Biesheuvel wrote: > > > > > Thumb2 code uses R7 as the frame pointer rather than R11, because the > > > opcodes to access it are generally shorter. > > > > > > This means that there are cases where we cannot simply add it to the > > > clobber list of an asm() block, but need to preserve/restore it > > > explicitly, or the compiler may complain in some cases (e.g., Clang > > > builds with ftrace enabled). > > > > > > Since R11 is not special in that case, clobber it instead, and use it to > > > preserve/restore the value of R7. > > > > Thanks Ard for fixing thumb2 issue! > > No problem. Although I'm still not 100% sure we can simply > preserve/restore the frame pointer like that. What is the expected > result when an exception occurs in the kprobes emulation code? What kind of exception would you mean? If it is a synchronous exception and can return to where the exception happens, the all registers must be restored. So as long as it is restored it is OK to me. > The main problem is that with unwind info unwinding, the stack pointer > and the frame pointer need to be mutually in sync, and with the > kprobes stack frames in the middle, this is no longer correct - the > emulated code is executed with the frame pointer value that was > captured when the probe was hit, by the stack has a couple of frames > added. > > > BTW, have you build the kernel with CONFIG_KPROBES_SANITY_TEST=y? > > It should check the backtrace from kprobe and kretprobe at boot time. > > > > Just checked, and those work fine. Thank you for testing! Reviewed-by: Masami Hiramatsu Thank you, -- Masami Hiramatsu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel