From patchwork Fri Sep 14 03:40:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 969602 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42BLtP5v9kz9s9N for ; Fri, 14 Sep 2018 13:42:05 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="io6pyy9j"; dkim-atps=neutral Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 42BLtP4Gp5zF3TN for ; Fri, 14 Sep 2018 13:42:05 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="io6pyy9j"; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::644; helo=mail-pl1-x644.google.com; envelope-from=amodra@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="io6pyy9j"; dkim-atps=neutral Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42BLrC5ZPxzF3TN for ; Fri, 14 Sep 2018 13:40:11 +1000 (AEST) Received: by mail-pl1-x644.google.com with SMTP id b12-v6so3532784plr.8 for ; Thu, 13 Sep 2018 20:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JKr3XGWjFz6PGfZCOtsqrufgtF4soIYKGLV/PZFfGWA=; b=io6pyy9jJ4QfkCC/0csrJlJ1dzsgCA1bISDZIxe1KbiXxSKUPWn7sG6zje/aIkwC0i cz/qkCVZESVsUapNCp9VYolcxbiso9ogdZ0iBPxo6FLGefx9PwbO4kTE2j0+pvwZ7+a4 sRYVp0fopR9vBLXcEUSmUNM1U1bb/nkJtVj48uQXfSf5z9Z5JTQKcn0c05Bvb+8vxs6b b5g2epuy3VmSCJSnw/ksQyERvVfutzqvaHHRSTBhMLAQCvgFDZRma35kBw0TADno95b+ vZ+rFwEsSEbiI0F9Q1t5F9/xxkBluX2lhhRInnaNLWGkaZEHPQFX6uU2WipGG6NQLITM Ha4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JKr3XGWjFz6PGfZCOtsqrufgtF4soIYKGLV/PZFfGWA=; b=rzWKxXNukD+pJZYlGf4mhxDBW8wFEBO2e9zGXLcmfsVK389BbcZQXBWk/7cMVxWUbO x1BD632B75QdJFoTUE3P0C7Lxg7NfCI+o8x0INm3hmeT3/6fA5gEwlKIbW+D9cZk/oB5 019r3jh6CrEJXaRsNwIDxz4CwYBxfZj3ZfI54OZ5fT5GtWEfaGiTSMa7rquUzhBZ+AB/ 5NF/OyEv6lwItxFnVr0N2uwDXbiHZuHBXyS5BA0rN4Up2RYDrFFkQAOq6EAWv84F+MD1 w5zRHl1djWd9u94lix9zuc7PbatQngQIAvQ1GLaPGB+dAruYfY3DJBbZDge8cXKLBgto uXZQ== X-Gm-Message-State: APzg51CuKSt81ZSUbMTplohQcr308AYJVg/Kqc+w82scBJzMKeKtHgvP ME2pRUtZKSO9tnUj8Be6ylAdDksF X-Google-Smtp-Source: ANB0VdYOHVQcw1cts9iIzF7vvK1jfQNJQrvlNC1Hcl5XIjoSOp5BFyDWLnw/vLjdQR6nljPDyb2SUw== X-Received: by 2002:a17:902:4d46:: with SMTP id o6-v6mr1856087plh.59.1536896409732; Thu, 13 Sep 2018 20:40:09 -0700 (PDT) Received: from bubble.grove.modra.org ([58.175.241.133]) by smtp.gmail.com with ESMTPSA id h132-v6sm7396392pfc.100.2018.09.13.20.40.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Sep 2018 20:40:08 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id F0337802D5; Fri, 14 Sep 2018 13:10:04 +0930 (ACST) Date: Fri, 14 Sep 2018 13:10:04 +0930 From: Alan Modra To: Michael Neuling Subject: [PATCH] PowerPC/VDSO: Correct call frame information Message-ID: <20180914034004.GP3174@bubble.grove.modra.org> References: <20180913232704.GL3174@bubble.grove.modra.org> <545f4cb2ca6f8d678798a387ea189bcf152842f9.camel@neuling.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <545f4cb2ca6f8d678798a387ea189bcf152842f9.camel@neuling.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" Call Frame Information is used by gdb for back-traces and inserting breakpoints on function return for the "finish" command. This failed when inside __kernel_clock_gettime. More concerning than difficulty debugging is that CFI is also used by stack frame unwinding code to implement exceptions. If you have an app that needs to handle asynchronous exceptions for some reason, and you are unlucky enough to get one inside the VDSO time functions, your app will crash. What's wrong: There is control flow in __kernel_clock_gettime that reaches label 99 without saving lr in r12. CFI info however is interpreted by the unwinder without reference to control flow: It's a simple matter of "Execute all the CFI opcodes up to the current address". That means the unwinder thinks r12 contains the return address at label 99. Disabuse it of that notion by resetting CFI for the return address at label 99. Note that the ".cfi_restore lr" could have gone anywhere from the "mtlr r12" a few instructions earlier to the instruction at label 99. I put the CFI as late as possible, because in general that's best practice (and if possible grouped with other CFI in order to reduce the number of CFI opcodes executed when unwinding). Using r12 as the return address is perfectly fine after the "mtlr r12" since r12 on that code path still contains the return address. __get_datapage also has a CFI error. That function temporarily saves lr in r0, and reflects that fact with ".cfi_register lr,r0". A later use of r0 means the CFI at that point isn't correct, as r0 no longer contains the return address. Fix that too. Signed-off-by: Alan Modra Tested-by: Reza Arbab diff --git a/arch/powerpc/kernel/vdso32/datapage.S b/arch/powerpc/kernel/vdso32/datapage.S index 3745113fcc65..2a7eb5452aba 100644 --- a/arch/powerpc/kernel/vdso32/datapage.S +++ b/arch/powerpc/kernel/vdso32/datapage.S @@ -37,6 +37,7 @@ data_page_branch: mtlr r0 addi r3, r3, __kernel_datapage_offset-data_page_branch lwz r0,0(r3) + .cfi_restore lr add r3,r0,r3 blr .cfi_endproc diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S b/arch/powerpc/kernel/vdso32/gettimeofday.S index 769c2624e0a6..1e0bc5955a40 100644 --- a/arch/powerpc/kernel/vdso32/gettimeofday.S +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S @@ -139,6 +139,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime) */ 99: li r0,__NR_clock_gettime + .cfi_restore lr sc blr .cfi_endproc diff --git a/arch/powerpc/kernel/vdso64/datapage.S b/arch/powerpc/kernel/vdso64/datapage.S index abf17feffe40..bf9668691511 100644 --- a/arch/powerpc/kernel/vdso64/datapage.S +++ b/arch/powerpc/kernel/vdso64/datapage.S @@ -37,6 +37,7 @@ data_page_branch: mtlr r0 addi r3, r3, __kernel_datapage_offset-data_page_branch lwz r0,0(r3) + .cfi_restore lr add r3,r0,r3 blr .cfi_endproc diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S b/arch/powerpc/kernel/vdso64/gettimeofday.S index c002adcc694c..a4ed9edfd5f0 100644 --- a/arch/powerpc/kernel/vdso64/gettimeofday.S +++ b/arch/powerpc/kernel/vdso64/gettimeofday.S @@ -169,6 +169,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime) */ 99: li r0,__NR_clock_gettime + .cfi_restore lr sc blr .cfi_endproc