All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-arm-kernel@lists.infradead.org, gregory.herrero@oracle.com,
	Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.
Date: Wed, 22 Jul 2020 17:36:50 +0100	[thread overview]
Message-ID: <20200722163650.GI27540@gaia> (raw)
In-Reply-To: <20200717133003.025f2096@oasis.local.home>

On Fri, Jul 17, 2020 at 01:30:03PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2020 16:33:38 +0200
> gregory.herrero@oracle.com wrote:
> > From: Gregory Herrero <gregory.herrero@oracle.com>
> > Currently, if a section has a relocation to '_mcount' symbol, a new
> > __mcount_loc entry will be added whatever the relocation type is.
> > This is problematic when a relocation to '_mcount' is in the middle of a
> > section and is not a call for ftrace use.
> > 
> > Such relocation could be generated with below code for example:
> >     bool is_mcount(unsigned long addr)
> >     {
> >         return (target == (unsigned long) &_mcount);
> >     }
> > 
> > With this snippet of code, ftrace will try to patch the mcount location
> > generated by this code on module load and fail with:
> > 
> >     Call trace:
> >      ftrace_bug+0xa0/0x28c
> >      ftrace_process_locs+0x2f4/0x430
> >      ftrace_module_init+0x30/0x38
> >      load_module+0x14f0/0x1e78
> >      __do_sys_finit_module+0x100/0x11c
> >      __arm64_sys_finit_module+0x28/0x34
> >      el0_svc_common+0x88/0x194
> >      el0_svc_handler+0x38/0x8c
> >      el0_svc+0x8/0xc
> >     ---[ end trace d828d06b36ad9d59 ]---
> >     ftrace failed to modify
> >     [<ffffa2dbf3a3a41c>] 0xffffa2dbf3a3a41c
> >      actual:   66:a9:3c:90
> >     Initializing ftrace call sites
> >     ftrace record flags: 2000000
> >      (0)
> >     expected tramp: ffffa2dc6cf66724
> > 
> > So Limit the relocation type to R_AARCH64_CALL26 as in perl version of
> > recordmcount.
> 
> I'd rather have this go through the arm64 tree, as they can test it
> better than I can.
> 
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Thanks Steve.

> > Fixes: ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount")

This Fixes tag looks wrong. The above commit was for arm32.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: gregory.herrero@oracle.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.
Date: Wed, 22 Jul 2020 17:36:50 +0100	[thread overview]
Message-ID: <20200722163650.GI27540@gaia> (raw)
In-Reply-To: <20200717133003.025f2096@oasis.local.home>

On Fri, Jul 17, 2020 at 01:30:03PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2020 16:33:38 +0200
> gregory.herrero@oracle.com wrote:
> > From: Gregory Herrero <gregory.herrero@oracle.com>
> > Currently, if a section has a relocation to '_mcount' symbol, a new
> > __mcount_loc entry will be added whatever the relocation type is.
> > This is problematic when a relocation to '_mcount' is in the middle of a
> > section and is not a call for ftrace use.
> > 
> > Such relocation could be generated with below code for example:
> >     bool is_mcount(unsigned long addr)
> >     {
> >         return (target == (unsigned long) &_mcount);
> >     }
> > 
> > With this snippet of code, ftrace will try to patch the mcount location
> > generated by this code on module load and fail with:
> > 
> >     Call trace:
> >      ftrace_bug+0xa0/0x28c
> >      ftrace_process_locs+0x2f4/0x430
> >      ftrace_module_init+0x30/0x38
> >      load_module+0x14f0/0x1e78
> >      __do_sys_finit_module+0x100/0x11c
> >      __arm64_sys_finit_module+0x28/0x34
> >      el0_svc_common+0x88/0x194
> >      el0_svc_handler+0x38/0x8c
> >      el0_svc+0x8/0xc
> >     ---[ end trace d828d06b36ad9d59 ]---
> >     ftrace failed to modify
> >     [<ffffa2dbf3a3a41c>] 0xffffa2dbf3a3a41c
> >      actual:   66:a9:3c:90
> >     Initializing ftrace call sites
> >     ftrace record flags: 2000000
> >      (0)
> >     expected tramp: ffffa2dc6cf66724
> > 
> > So Limit the relocation type to R_AARCH64_CALL26 as in perl version of
> > recordmcount.
> 
> I'd rather have this go through the arm64 tree, as they can test it
> better than I can.
> 
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Thanks Steve.

> > Fixes: ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount")

This Fixes tag looks wrong. The above commit was for arm32.

-- 
Catalin

  parent reply	other threads:[~2020-07-22 16:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 14:33 [PATCH] recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64 gregory.herrero
2020-07-17 15:18 ` Greg KH
2020-07-17 17:30 ` Steven Rostedt
2020-07-17 17:30   ` Steven Rostedt
2020-07-17 20:01   ` Gregory Herrero
2020-07-17 20:15     ` Steven Rostedt
2020-07-17 20:15       ` Steven Rostedt
2020-07-22 16:36   ` Catalin Marinas [this message]
2020-07-22 16:36     ` Catalin Marinas
2020-07-22 18:50     ` Gregory Herrero
2020-07-22 18:50       ` Gregory Herrero
2020-07-23 11:52 ` Mark Rutland
2020-07-23 12:44   ` Gregory Herrero
2020-07-24 12:14 ` Catalin Marinas

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=20200722163650.GI27540@gaia \
    --to=catalin.marinas@arm.com \
    --cc=gregory.herrero@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.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.