All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Anton Arapov <aarapov@redhat.com>,
	David Long <dave.long@linaro.org>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Jim Keniston <jkenisto@us.ibm.com>,
	Jonathan Lebon <jlebon@redhat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] uprobes/x86: cleanup "riprel" functions
Date: Sun, 27 Apr 2014 18:52:01 +0200	[thread overview]
Message-ID: <20140427165200.GA3956@redhat.com> (raw)
In-Reply-To: <20140417200228.GA31097@redhat.com>

On 04/25, Oleg Nesterov wrote:
>
> On 04/17, Oleg Nesterov wrote:
> >
> > This series only fixes the problem. I'll send more changes to address
> > some of TODO's mentioned in the changelogs later.
>
> This is probably the last series I am sending in this thread, before the
> next PULL request. This completes the changes which I planned from the
> very beginning, except "emulate jczx/loopz" which I am still unsure about.

I lied, let me send another short series.

I was not going to do this now, I am a bit tired of uprobes ;) But it seems
that Denys has a very good idea, we can simplify rip-relative handling.

However, if we are are going to change this code, imho we need to cleanup it
first. handle_riprel_insn(), pre_xol_rip_insn() and handle_riprel_post_xol()
look really annoying, imho. Even the naming asks for the cleanup imo, despite
the fact that usually I ignore the naming completely.

Oleg.

 arch/x86/kernel/uprobes.c |   56 +++++++++++++++++++++------------------------
 1 files changed, 26 insertions(+), 30 deletions(-)


  parent reply	other threads:[~2014-04-27 16:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 20:02 [GIT PULL] uprobes: fix the handling of relative jmp/call's Oleg Nesterov
2014-04-18  8:35 ` Ingo Molnar
2014-04-19 17:01 ` [PATCH 0/5] uprobes/x86: cleanup validate_insn_* paths, fix X86_X32 case Oleg Nesterov
2014-04-19 17:01   ` [PATCH 1/5] uprobes/x86: Add uprobe_init_insn(), kill validate_insn_{32,64}bits() Oleg Nesterov
2014-04-29 10:04     ` Srikar Dronamraju
2014-04-19 17:01   ` [PATCH 2/5] uprobes/x86: Add is_64bit_mm(), kill validate_insn_bits() Oleg Nesterov
2014-04-29 10:05     ` Srikar Dronamraju
2014-04-19 17:01   ` [PATCH 3/5] uprobes/x86: Shift "insn_complete" from branch_setup_xol_ops() to uprobe_init_insn() Oleg Nesterov
2014-04-29 10:05     ` Srikar Dronamraju
2014-04-19 17:01   ` [PATCH 4/5] uprobes/x86: Make good_insns_* depend on CONFIG_X86_* Oleg Nesterov
2014-04-29 10:06     ` Srikar Dronamraju
2014-04-19 17:02   ` [PATCH 5/5] uprobes/x86: Fix is_64bit_mm() with CONFIG_X86_X32 Oleg Nesterov
2014-04-29 10:06     ` Srikar Dronamraju
2014-04-24 21:36   ` [PATCH 0/5] uprobes/x86: cleanup validate_insn_* paths, fix X86_X32 case Jim Keniston
2014-04-22 14:47 ` [PATCH 0/5] uprobes/x86: completely untangle branch_xol_ops and default_xol_ops Oleg Nesterov
2014-04-22 14:47   ` [PATCH 1/5] uprobes/x86: Don't change the task's state if ->pre_xol() fails Oleg Nesterov
2014-04-22 14:47   ` [PATCH 2/5] uprobes/x86: Introduce uprobe_xol_ops->abort() and default_abort_op() Oleg Nesterov
2014-04-22 14:47   ` [PATCH 3/5] uprobes/x86: Don't use arch_uprobe_abort_xol() in arch_uprobe_post_xol() Oleg Nesterov
2014-04-22 14:47   ` [PATCH 4/5] uprobes/x86: Move UPROBE_FIX_SETF logic from arch_uprobe_post_xol() to default_post_xol_op() Oleg Nesterov
2014-04-22 14:47   ` [PATCH 5/5] uprobes/x86: Move default_xol_ops's data into arch_uprobe->def Oleg Nesterov
2014-04-24 23:30     ` Jim Keniston
2014-04-25 19:53       ` Oleg Nesterov
2014-04-25 17:47 ` [PATCH 0/4] uprobes/x86: UPROBE_FIX_IP/UPROBE_FIX_CALL cleanups Oleg Nesterov
2014-04-25 17:47   ` [PATCH 1/4] uprobes/x86: Cleanup the usage of arch_uprobe->def.fixups, make it u8 Oleg Nesterov
2014-04-25 17:47   ` [PATCH 2/4] uprobes/x86: Introduce push_ret_address() Oleg Nesterov
2014-04-25 17:47   ` [PATCH 3/4] uprobes/x86: Kill adjust_ret_addr(), simplify UPROBE_FIX_CALL logic Oleg Nesterov
2014-04-25 17:47   ` [PATCH 4/4] uprobes/x86: Cleanup the usage of UPROBE_FIX_IP/UPROBE_FIX_CALL Oleg Nesterov
2014-04-27 13:51   ` [PATCH 0/4] uprobes/x86: UPROBE_FIX_IP/UPROBE_FIX_CALL cleanups Oleg Nesterov
2014-04-27 16:52 ` Oleg Nesterov [this message]
2014-04-27 16:52   ` [PATCH 1/3] uprobes/x86: Rename *riprel* helpers to make the naming consistent Oleg Nesterov
2014-04-28  6:34     ` Srikar Dronamraju
2014-05-01  0:07       ` Jim Keniston
2014-04-27 16:52   ` [PATCH 2/3] uprobes/x86: Kill the "autask" arg of riprel_pre_xol() Oleg Nesterov
2014-04-28  6:35     ` Srikar Dronamraju
2014-05-01  0:07       ` Jim Keniston
2014-04-27 16:52   ` [PATCH 3/3] uprobes/x86: Simplify riprel_{pre,post}_xol() and make them similar Oleg Nesterov
2014-04-28  6:36     ` Srikar Dronamraju
2014-05-01  0:08       ` 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=20140427165200.GA3956@redhat.com \
    --to=oleg@redhat.com \
    --cc=aarapov@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=dave.long@linaro.org \
    --cc=dvlasenk@redhat.com \
    --cc=fche@redhat.com \
    --cc=jkenisto@us.ibm.com \
    --cc=jlebon@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --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.