All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>, Yang Shi <yang.shi@linaro.org>,
	linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: remove redundant FRAME_POINTER kconfig option
Date: Fri, 6 Nov 2015 16:21:09 +0000	[thread overview]
Message-ID: <20151106162109.GZ7637@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <20151106125002.GA8116@leverpostej>

On Fri, Nov 06, 2015 at 12:50:02PM +0000, Mark Rutland wrote:
> On Fri, Nov 06, 2015 at 12:30:09PM +0000, Will Deacon wrote:
> > On Wed, Nov 04, 2015 at 09:37:51AM -0800, Yang Shi wrote:
> > > FRAME_POINTER is defined in lib/Kconfig.debug, it is unnecessary to redefine
> > > it in arch/arm64/Kconfig.debug.
> > 
> > It might be worth noting that this adds a dependency on DEBUG_KERNEL
> > for building with frame pointers. I'm ok with that (it appears to be
> > enabled in defconfig and follows the vast majority of other archs) but
> > it is a change in behaviour.
> > 
> > With that:
> > 
> >   Acked-by: Will Deacon <will.deacon@arm.com>
> 
> The code in arch/arm64/kernel/stacktrace.c assumes we have frame
> pointers regardless of FRAME_POINTER. Depending on what the compiler
> decides to use x29 for, we could get some weird fake unwinding and/or
> dodgy memory accesses.
> 
> I think we should first audit the uses of frame pointers to ensure that
> they are guarded for !FRAME_POINTER.

Or we just select FRAME_POINTER in the ARM64 Kconfig entry.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: remove redundant FRAME_POINTER kconfig option
Date: Fri, 6 Nov 2015 16:21:09 +0000	[thread overview]
Message-ID: <20151106162109.GZ7637@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <20151106125002.GA8116@leverpostej>

On Fri, Nov 06, 2015 at 12:50:02PM +0000, Mark Rutland wrote:
> On Fri, Nov 06, 2015 at 12:30:09PM +0000, Will Deacon wrote:
> > On Wed, Nov 04, 2015 at 09:37:51AM -0800, Yang Shi wrote:
> > > FRAME_POINTER is defined in lib/Kconfig.debug, it is unnecessary to redefine
> > > it in arch/arm64/Kconfig.debug.
> > 
> > It might be worth noting that this adds a dependency on DEBUG_KERNEL
> > for building with frame pointers. I'm ok with that (it appears to be
> > enabled in defconfig and follows the vast majority of other archs) but
> > it is a change in behaviour.
> > 
> > With that:
> > 
> >   Acked-by: Will Deacon <will.deacon@arm.com>
> 
> The code in arch/arm64/kernel/stacktrace.c assumes we have frame
> pointers regardless of FRAME_POINTER. Depending on what the compiler
> decides to use x29 for, we could get some weird fake unwinding and/or
> dodgy memory accesses.
> 
> I think we should first audit the uses of frame pointers to ensure that
> they are guarded for !FRAME_POINTER.

Or we just select FRAME_POINTER in the ARM64 Kconfig entry.

-- 
Catalin

  parent reply	other threads:[~2015-11-06 16:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04 17:37 [PATCH] arm64: remove redundant FRAME_POINTER kconfig option Yang Shi
2015-11-04 17:37 ` Yang Shi
2015-11-06 12:30 ` Will Deacon
2015-11-06 12:30   ` Will Deacon
2015-11-06 12:50   ` Mark Rutland
2015-11-06 12:50     ` Mark Rutland
2015-11-06 15:42     ` Will Deacon
2015-11-06 15:42       ` Will Deacon
2015-11-06 16:21     ` Catalin Marinas [this message]
2015-11-06 16:21       ` Catalin Marinas
2015-11-06 16:25       ` Will Deacon
2015-11-06 16:25         ` Will Deacon
2015-11-06 17:23         ` Shi, Yang
2015-11-06 17:23           ` Shi, Yang
2015-11-06 17:35           ` Catalin Marinas
2015-11-06 17:35             ` Catalin Marinas
2015-11-06 17:39             ` Shi, Yang
2015-11-06 17:39               ` Shi, Yang
2015-11-06 17:51               ` Catalin Marinas
2015-11-06 17:51                 ` Catalin Marinas
2015-11-06 17:55                 ` Shi, Yang
2015-11-06 17:55                   ` Shi, Yang
2015-11-09 15:58                   ` Catalin Marinas
2015-11-09 15:58                     ` Catalin Marinas
2015-11-06 16:12   ` Catalin Marinas
2015-11-06 16:12     ` Catalin Marinas
2015-11-06 16:19     ` Will Deacon
2015-11-06 16:19       ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151106162109.GZ7637@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=will.deacon@arm.com \
    --cc=yang.shi@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.