From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Vojtech Pavlik <vojtech@suse.cz>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Jiri Kosina <jkosina@suse.cz>, Jiri Slaby <jslaby@suse.cz>,
linux390@de.ibm.com, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] s390: add support for DYNAMIC_FTRACE_WITH_REGS
Date: Fri, 15 Aug 2014 13:57:53 +0200 [thread overview]
Message-ID: <20140815115753.GA4215@osiris> (raw)
In-Reply-To: <20140708080740.GA4491@osiris>
On Tue, Jul 08, 2014 at 10:07:40AM +0200, Heiko Carstens wrote:
> On Thu, Jul 03, 2014 at 02:00:46PM +0200, Vojtech Pavlik wrote:
> > Add support for DYNAMIC_FTRACE_WITH_REGS to 64-bit and 31-bit s390
> > architectures. This is required for kGraft and kpatch to work on s390.
> >
> > It's done by adding a _regs variant of ftrace_caller that preserves
> > registers and puts them on stack in a struct pt_regs layout and
> > allows modification of return address by changing the PSW (instruction
> > pointer) member od struct pt_regs.
> >
> > Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
> > Reviewed-by: Jiri Kosina <jkosina@suse.cz>
> > Cc: Steven Rostedt <rostedt@goodmis.org>
>
> So I assume you use the instruction_pointer() macro to access the
> return address then?
>
> All of this seems a bit of a hack to me.. the natural place of the
> return address of a function would be register 14, and not the
> psw member of the pt_regs structure.
>
> It's then also inconsistent to only save register r0-r13 to the
> gprs member.. well, you can't save r14, since what should
> happen if both r14 in the gprs member of pt_regs and in the psw
> part would have been changed?
>
> Besides that a couple more comments below.
[...]
> Some objections: this code assumes that sizeof(struct pt_regs) does not
> change, which is not correct. So as soon as we touch struct pt_regs this
> code would be broken. Also the order of the members within struct pt_regs
> is not necessarily static (pt_regs is not ABI).
FWIW, this already happened with d3a73acbc26a4a81a01a35fd162973e53d0386f5
"s390: split TIF bits into CIF, PIF and TIF bits".
Anyway, since I didn't got any response from you during the last couple of
weeks, I changed the ftrace code so it should fit your needs.
I will send five patches in reply to this mail - patch 4 of 5 is the one
that implements the DYNAMIC_FTRACE_WITH_REGS functionality, how differently
to your patch, especially possible return address changing.
next prev parent reply other threads:[~2014-08-15 11:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 12:00 [PATCH] s390: add support for DYNAMIC_FTRACE_WITH_REGS Vojtech Pavlik
2014-07-08 8:07 ` Heiko Carstens
2014-08-15 11:57 ` Heiko Carstens [this message]
2014-08-15 11:59 ` [PATCH 1/5] s390: pass march flag to assembly files as well Heiko Carstens
2014-08-15 11:59 ` [PATCH 2/5] s390/ftrace: optimize patched mcount calling code Heiko Carstens
2014-08-15 12:00 ` [PATCH 3/5] s390/ftrace: optimize function graph caller code Heiko Carstens
2014-08-15 12:00 ` [PATCH 4/5] s390/ftrace: add HAVE_DYNAMIC_FTRACE_WITH_REGS support Heiko Carstens
2014-08-15 12:01 ` [PATCH 5/5] s390/ftrace: enforce DYNAMIC_FTRACE if FUNCTION_TRACER is selected Heiko Carstens
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=20140815115753.GA4215@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=jkosina@suse.cz \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=rostedt@goodmis.org \
--cc=schwidefsky@de.ibm.com \
--cc=vojtech@suse.cz \
/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.