Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1707670ybt; Thu, 18 Jun 2020 15:28:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUmsSuD/C2c+rTadoJekoNSRYPnYTG6uWcCi35vYl7xd6KILOExVY7GyuDdemCNnMJSFsl X-Received: by 2002:a05:6402:22b3:: with SMTP id cx19mr364079edb.329.1592519317800; Thu, 18 Jun 2020 15:28:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592519317; cv=none; d=google.com; s=arc-20160816; b=nmXIqrp1PIq9JWvqS69AAASgidWC/xKul7bI3OyyLQEwRPQzWwk8uCQJ7Zo2tfI8OM sxuO2DvHmHd2a8qxKb4MtLMxuvJfvgztZeJqdJN3y+umabUGn+/l/toQy5NRq0W4Ipov xV9jP7+JbOwWBaAocf0h6aZiCN3e4KfPl16qhDXbc5vEpOlssN5epH8B03nXyMYu9+Dq S+c+KXGNzyrjKOmSRBLCTTmnteTm4spisYJzfrZAZp/x/lKivXvnQv3SAbzoOEgOsC7g BIUwBOror3c61okSVGyhPcpjJ8dTrC5E1NY7QaBN2ReEyNFqCirs9t+9VFARaafL26oA t8ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ApmvY4NUh4oE4rGYTLrhVzjNJ6MG1aD54ijaoWc+qQQ=; b=Y2Q5qmmekTeck53OqDj1+6KwfpNdYzrhxwEf/0bCCPZb/0viW9/8gUMRL64L2nGDqb ahuA1snC9v27TwxpgmrMUSOGgBKTxqptaOdHXJlQmDKg8MS3V0H3zK1a0ZXnMOX3Aaff cjvCZZ8IsNvGNa0JTEAjKOBQ1cTYMT1YhPO7c7oDd9xuZjzV/GC4+4eR67nY/sLLGgJ5 yboxdaKxVzQ/MjqC2ztEV9FRxC5RqTYAaEUzLfEHTU5Dk2yVHuZhtdoCVhj8p9YEjpvc idaTRPAqzT/aKycnVAwAnevwHrimON6lbE17Cf8OmgS6V1hL5JmkQk4+IwRfSpj2YkU4 4CcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Mg8xt2oO; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de3si2723370edb.295.2020.06.18.15.28.15; Thu, 18 Jun 2020 15:28:37 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=Mg8xt2oO; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728851AbgFRU3O (ORCPT + 99 others); Thu, 18 Jun 2020 16:29:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726193AbgFRU3N (ORCPT ); Thu, 18 Jun 2020 16:29:13 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D414EC06174E for ; Thu, 18 Jun 2020 13:29:13 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id u8so3057645pje.4 for ; Thu, 18 Jun 2020 13:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ApmvY4NUh4oE4rGYTLrhVzjNJ6MG1aD54ijaoWc+qQQ=; b=Mg8xt2oOvSVJzdadsLPdjjKqP24SfmArTOufNfznQyUZcY1XPsLBbTgvCVJWSX23t1 zlpTrHNr+laRY2ihyOiL5y0qWnyU7iOidLPFb/3RVtE/52HkV3ziLN6ooNxyhjYYMp2o ZYgnU5Uwv+1P8BufZc/VcW8TQCVa4h83/NtTx/fWssW0TjsgWTMlBq5/y7r9eRSjrACh MKajyjltSPlhfBv9mvwMLTAzBiGi1tA1bqWc5jNwv8QjQJHVZj9wOOXPVL5TN+rTEoJa LurVgqBnek49Ec5FNrnxuD74mbVSwh3av+KXedrr52YLkEdMb2Fe01DerkWmloglOOAc NH0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ApmvY4NUh4oE4rGYTLrhVzjNJ6MG1aD54ijaoWc+qQQ=; b=Et3P8PuCuYStnDByaHRQSaCS2xjv9Xhrw94+wtGuQ2x8zQGsBzZFo6Op5TUBCsBNAd g2RWr59jBiC6ctIoEVe3/oNqrqQtw2TOgs4P+2aN59Akb3rh+qlhRpqZJ+YYX5efvjy0 CdeaLLym+ay1QLgeDiXYWlSum3xT4Kz4fRphipOFK/b8PeGxRTGYATxZyq30PRNERoM6 qAZAItMhTVQv5kGMmnp8aO+xEKKRBRdcIZN7YrSoq/8IVFt0Cha0UGSbE80+M9HdDQ3V /FdzZdrCgVFGfzfH4xsDdLQol2yGVcZcDHkjz0HNctSsrMLsN3jMUKSrn6+qrj6Lh4CG UxBg== X-Gm-Message-State: AOAM530VgDZ4pnxJ9YopFh9Yr86GZJE9lCIV3nBNqISPMIp67WtLpyDA TZNYevCyicAJ++4o6ug9j25fl0RE0w7fnA0aWZnAGg== X-Received: by 2002:a17:90a:e2c4:: with SMTP id fr4mr127063pjb.32.1592512153032; Thu, 18 Jun 2020 13:29:13 -0700 (PDT) MIME-Version: 1.0 References: <20200616223633.73971-1-nhuck@google.com> In-Reply-To: From: Nick Desaulniers Date: Thu, 18 Jun 2020 13:29:01 -0700 Message-ID: Subject: Re: [PATCH] Fix unwind_frame for clang-built kernels To: Nathan Huckleberry , =?UTF-8?B?TWlsZXMgQ2hlbiAo6Zmz5rCR5qi6KQ==?= Cc: Russell King , Vincent Whitchurch , Linux ARM , LKML , clang-built-linux , Sedat Dilek , Catalin Marinas , Kristof Beyls Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 18, 2020 at 1:22 PM Nick Desaulniers wrote: > > On Tue, Jun 16, 2020 at 3:36 PM 'Nathan Huckleberry' via Clang Built > Linux wrote: > > > > Since clang does not push pc and sp in function prologues, the current > > implementation of unwind_frame does not work. By using the previous > > frame's lr/fp instead of saved pc/sp we get valid unwinds on clang-built > > kernels. > > > > The bounds check on next frame pointer must be changed as well since > > there are 8 less bytes between frames. > > > > This fixes /proc//stack. > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/912 > > Signed-off-by: Nathan Huckleberry > > Thanks for the patch, Nathan! When I looked into this, I found the > latest ARM AAPCS [0] specifically says (with `it` referring to `a > platform`: "It may permit the frame pointer register to be used as a > general-purpose callee-saved register, but provide a platform-specific > mechanism for external agents to reliably locate the chain of frame > records." While it's good that's acknowledged in the documentation, > the current wording is relaxed in order to not force current > implementations to converge. This has the unfortunate side effect of > making finding the frame pointer toolchain dependendent, hence this > patch and your previous commit 6dc5fd93b2f1 ("ARM: 8900/1: > UNWINDER_FRAME_POINTER implementation for Clang"). Being more > specific in the documentation would force at least one implementation > to change, and I think that would also imply an ABI break. So I can > see it both ways, though I still would prefer that the language pin > this down, even if we had to change LLVM. Just providing additional > context for folks on the thread. > > This should also have a reported by tag from Miles, in v2. > > Reported-by: Miles Chen > > Miles mentioned to me that he tested it, but maybe Miles can confirm > that publicly on-list via an explicit Tested-by: tag? > > This would be useful for us to have in stable; otherwise we'll have to > carry out of tree in Android and CrOS, which I'd rather not do. Via > Documentation/process/stable-kernel-rules.rst, if you add this tag to > V2, that will greatly simplify submitting this to stable: > Cc: stable@vger.kernel.org > > Miles also showed me the behavior of this patch for different kernel s/this patch/this function before this patch is applied/ > versions, which varies anywhere from empty or single entry traces to > panics, so this is pretty important that this works for Clang builds. > > [0] https://static.docs.arm.com/ihi0042/i/aapcs32.pdf > > > --- > > arch/arm/kernel/stacktrace.c | 24 ++++++++++++++++++++++++ > > 1 file changed, 24 insertions(+) > > > > diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c > > index cc726afea023..76ea4178a55c 100644 > > --- a/arch/arm/kernel/stacktrace.c > > +++ b/arch/arm/kernel/stacktrace.c > > @@ -22,6 +22,19 @@ > > * A simple function epilogue looks like this: > > * ldm sp, {fp, sp, pc} > > * > > + * When compiled with clang, pc and sp are not pushed. A simple function > > + * prologue looks like this when built with clang: > > + * > > + * stmdb {..., fp, lr} > > + * add fp, sp, #x > > + * sub sp, sp, #y > > + * > > + * A simple function epilogue looks like this when built with clang: > > + * > > + * sub sp, fp, #x > > + * ldm {..., fp, pc} > > + * > > + * > > * Note that with framepointer enabled, even the leaf functions have the same > > * prologue and epilogue, therefore we can ignore the LR value in this case. > > */ > > @@ -34,6 +47,16 @@ int notrace unwind_frame(struct stackframe *frame) > > low = frame->sp; > > high = ALIGN(low, THREAD_SIZE); > > > > +#ifdef CONFIG_CC_IS_CLANG > > + /* check current frame pointer is within bounds */ > > + if (fp < low + 4 || fp > high - 4) > > The patch LGTM; maybe Russell or Catalin could triple check this > bounds check? Assuming there's no issue, you can include on a v2 my > reviewed by: > > Reviewed-by: Nick Desaulniers > > I'd probably wait the remainder of a week before sending a v2 to > collect additional feedback. Thank you again. > > > + return -EINVAL; > > + > > + frame->sp = frame->fp; > > + frame->fp = *(unsigned long *)(fp); > > + frame->pc = frame->lr; > > + frame->lr = *(unsigned long *)(fp + 4); > > +#else > > /* check current frame pointer is within bounds */ > > if (fp < low + 12 || fp > high - 4) > > return -EINVAL; > > @@ -42,6 +65,7 @@ int notrace unwind_frame(struct stackframe *frame) > > frame->fp = *(unsigned long *)(fp - 12); > > frame->sp = *(unsigned long *)(fp - 8); > > frame->pc = *(unsigned long *)(fp - 4); > > +#endif > > > > return 0; > > } > > -- > > 2.27.0.290.gba653c62da-goog > > > > -- > > -- > Thanks, > ~Nick Desaulniers -- Thanks, ~Nick Desaulniers