From: Oleg Nesterov <oleg@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH] uprobes: Document xol_area and arch_uprobe->insn/ixol
Date: Tue, 19 Nov 2013 17:25:45 +0100 [thread overview]
Message-ID: <20131119162545.GA776@redhat.com> (raw)
In-Reply-To: <20131111210327.GG18886@gmail.com>
On 11/11, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > On 11/11, Ingo Molnar wrote:
> > >
> > > You guys are changing code that reads like gobbledygook to people
> > > reading it for the first time.
> >
> > Not that I am trying to defense uprobes, but this is equally true for
> > any piece of kernel code, at least to me ;)
>
> I'm really not suggesting to do overly much - only for some minimal blurb
> like the scheduler has in most places:
OK. Let me try to make a first step to improve this a little bit...
How about the patch below? Srikar?
Subject: [PATCH] uprobes: Document xol_area and arch_uprobe->insn/ixol
Document xol_area and arch_uprobe.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
kernel/events/uprobes.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 51a7f53..b886a5e 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -73,6 +73,17 @@ struct uprobe {
struct inode *inode; /* Also hold a ref to inode */
loff_t offset;
unsigned long flags;
+
+ /*
+ * The generic code assumes that it has two members of unknown type
+ * owned by the arch-specific code:
+ *
+ * insn - copy_insn() saves the original instruction here for
+ * arch_uprobe_analyze_insn().
+ *
+ * ixol - potentially modified instruction to execute out of
+ * line, copied to xol_area by xol_get_insn_slot().
+ */
struct arch_uprobe arch;
};
@@ -86,6 +97,10 @@ struct return_instance {
};
/*
+ * Execute out of line area: anonymous executable mapping installed
+ * by the probed task to execute the copy of the original instruction
+ * mangled by set_swbp().
+ *
* On a breakpoint hit, thread contests for a slot. It frees the
* slot after singlestep. Currently a fixed number of slots are
* allocated.
--
1.5.5.1
next prev parent reply other threads:[~2013-11-19 16:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-09 19:03 [PATCH] uprobes: Cleanup !CONFIG_UPROBES decls, unexport xol_area Oleg Nesterov
2013-11-11 7:15 ` Srikar Dronamraju
2013-11-11 8:41 ` Ingo Molnar
2013-11-11 19:58 ` Oleg Nesterov
2013-11-11 21:03 ` Ingo Molnar
2013-11-19 16:25 ` Oleg Nesterov [this message]
2013-11-19 19:24 ` [PATCH] uprobes: Document xol_area and arch_uprobe->insn/ixol Ingo Molnar
2013-11-20 11:03 ` Srikar Dronamraju
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=20131119162545.GA776@redhat.com \
--to=oleg@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.