From: Oleg Nesterov <oleg@redhat.com>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jim Keniston <jkenisto@us.ibm.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCHv4] uprobes: simplify rip-relative handling
Date: Thu, 1 May 2014 20:50:58 +0200 [thread overview]
Message-ID: <20140501185058.GA17450@redhat.com> (raw)
In-Reply-To: <1398955966-7771-1-git-send-email-dvlasenk@redhat.com>
Thanks, I hope that Jim's ack still applies to this version.
On 05/01, Denys Vlasenko wrote:
>
> v4: Changed arch_uprobe_xol_was_trapped() comment to reflect new logic.
Hmm. I guess you meant arch_uprobe_post_xol()... please see below.
> static int default_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
> {
> struct uprobe_task *utask = current->utask;
> - long correction = (long)(utask->vaddr - utask->xol_vaddr);
>
> - riprel_post_xol(auprobe, regs, &correction);
> + riprel_post_xol(auprobe, regs);
> if (auprobe->def.fixups & UPROBE_FIX_IP) {
> + long correction = (long)(utask->vaddr - utask->xol_vaddr);
Can't resist, I'll remove this pointless cast ;)
> * If the original instruction was a rip-relative instruction such as
> * "movl %edx,0xnnnn(%rip)", we have instead executed an equivalent
> - * instruction using a scratch register -- e.g., "movl %edx,(%rax)".
> - * We need to restore the contents of the scratch register and adjust
> - * the ip, keeping in mind that the instruction we executed is 4 bytes
> - * shorter than the original instruction (since we squeezed out the offset
> - * field). (FIX_RIP_AX or FIX_RIP_CX)
> + * instruction using a scratch register -- e.g., "movl %edx,0xnnnn(%rax)".
> + * We need to restore the contents of the scratch register
> + * (FIX_RIP_AX or FIX_RIP_CX).
> */
> int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
Perhaps it makes sense to move this part of the comment above
default_post_xol_op() which actually does this...
I won't insist, I do not really care because I almost never read the comments
anyway ;)
Oleg.
next prev parent reply other threads:[~2014-05-01 18:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-01 14:52 [PATCHv4] uprobes: simplify rip-relative handling Denys Vlasenko
2014-05-01 18:50 ` Oleg Nesterov [this message]
2014-05-01 23:35 ` Jim Keniston
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=20140501185058.GA17450@redhat.com \
--to=oleg@redhat.com \
--cc=dvlasenk@redhat.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@kernel.org \
--cc=srikar@linux.vnet.ibm.com \
/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.