linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uprobes: Add uprobe_task->dup_work/dup_addr
Date: Mon, 11 Nov 2013 12:41:51 +0530	[thread overview]
Message-ID: <20131111071151.GA2559@linux.vnet.ibm.com> (raw)
In-Reply-To: <20131108190003.GA12755@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2013-11-08 20:00:03]:

> uprobe_task->vaddr is a bit strange. First of all it is not really
> needed, we can move it into arch_uprobe_task. The generic code uses
> it only to pass the additional argument to arch_uprobe_pre_xol(),
> and since it is always equal to instruction_pointer() this looks
> even more strange.
> 

While the code changes look good, I would disagree with the above
statement.  uprobe_task->vaddr is a bit strange only in
uprobe_copy_process() and not in arch_uprobe_pre_xol() context.
uprobe_task->vaddr was used to refer to the actual instruction pointer
and do the necessary fixups after single stepping out of line.

The casual reading of this commit message, one can get an impression
that vaddr is never needed.  Your change still retains it. So can we
modify the commit message accordingly? 

> And both utask->vaddr and and utask->autask have the same scope,
> they only have the meaning when the task executes the probed insn
> out-of-line. This means it is safe to reuse both in UTASK_RUNNING
> state.
> 
> OTOH, it is also used by uprobe_copy_process() and dup_xol_work()
> for another purpose, this doesn't look clean and doesn't allow to
> move this member into arch_uprobe_task.
> 
> This patch adds the union with 2 anonymous structs into uprobe_task.
> 
> The first struct is autask + vaddr, this way we "almost" move vaddr
> into autask.
> 
> The second struct has 2 new members for uprobe_copy_process() paths:
> ->dup_addr which can be used instead ->vaddr, and ->dup_work which
> can be used to avoid kmalloc() and simplify the code.
> 
> Note that this union will likely have another member(s), we need
> something like "private_data_for_handlers" so that the tracing
> handlers could use it to communicate with call_fetch() methods.

One nit below + request for change in the above commit message. 
Otherwise 
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
>  include/linux/uprobes.h |   21 ++++++++++++++++-----
>  kernel/events/uprobes.c |   16 ++++------------
>  2 files changed, 20 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index 319eae7..366b8b2 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -26,6 +26,7 @@
> 
>  #include <linux/errno.h>
>  #include <linux/rbtree.h>
> +#include <linux/types.h>
> 
>  struct vm_area_struct;
>  struct mm_struct;
> @@ -72,14 +73,24 @@ enum uprobe_task_state {
>   */
>  struct uprobe_task {
>  	enum uprobe_task_state		state;
> -	struct arch_uprobe_task		autask;
> 
> -	struct return_instance		*return_instances;
> -	unsigned int			depth;
> -	struct uprobe			*active_uprobe;
> +	union {
> +		struct {
> +			struct arch_uprobe_task	autask;
> +			unsigned long		vaddr;
> +		};
> +
> +		struct {
> +			struct callback_head	dup_work;
> +			unsigned long		dup_addr;

Nit:
Can we rename dup_addr to mean that it refers to the xol; something like
dup_xol_addr or even xol_addr. So that its more clear what address it
refers to.


-- 
Thanks and Regards
Srikar Dronamraju


  parent reply	other threads:[~2013-11-11  7:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08 19:00 [PATCH] uprobes: Add uprobe_task->dup_work/dup_addr Oleg Nesterov
2013-11-10 15:43 ` Masami Hiramatsu
2013-11-10 17:28   ` Oleg Nesterov
2013-11-11  1:37     ` Masami Hiramatsu
2013-11-11  1:43 ` Masami Hiramatsu
2013-11-11  7:11 ` Srikar Dronamraju [this message]
2013-11-11 16:55   ` Oleg Nesterov
2013-11-11 17:59     ` Oleg Nesterov
2013-11-12 17:43     ` Srikar Dronamraju
2013-11-12 19:20       ` [PATCH v2] " Oleg Nesterov
2013-11-13  5:22         ` Srikar Dronamraju
2013-11-24  8:19         ` Masami Hiramatsu
2013-11-25 12:10           ` Oleg Nesterov

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=20131111071151.GA2559@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).