linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: mhiramat@kernel.org (Masami Hiramatsu)
Subject: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features
Date: Mon, 7 May 2018 23:53:17 +0900	[thread overview]
Message-ID: <20180507235317.fa04131c603dbe59ef78a829@kernel.org> (raw)
Message-ID: <20180507145317.p0BBos4yYjRg1t4-g3Sqs7w8w0Qtcxj4BSY9JQAAajk@z> (raw)
In-Reply-To: <1525680222.8nou0tzkkt.naveen@linux.ibm.com>

On Mon, 07 May 2018 13:41:53 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:

> Masami Hiramatsu wrote:
> > On Sat, 05 May 2018 13:16:04 +0530
> > "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> > 
> >> Masami Hiramatsu wrote:
> >> > On Fri, 4 May 2018 12:06:42 -0400
> >> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >> > 
> >> >> On Sat, 5 May 2018 00:48:28 +0900
> >> >> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >> >> 
> >> >> > > Also, when looking at the kprobe code, I was looking at this 
> >> >> > > function:
> >> >> > >   
> >> >> > > > /* Ftrace callback handler for kprobes -- called under preepmt disabed */
> >> >> > > > void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> >> >> > > > 			   struct ftrace_ops *ops, struct pt_regs *regs)
> >> >> > > > {
> >> >> > > > 	struct kprobe *p;
> >> >> > > > 	struct kprobe_ctlblk *kcb;
> >> >> > > > 
> >> >> > > > 	/* Preempt is disabled by ftrace */
> >> >> > > > 	p = get_kprobe((kprobe_opcode_t *)ip);
> >> >> > > > 	if (unlikely(!p) || kprobe_disabled(p))
> >> >> > > > 		return;
> >> >> > > > 
> >> >> > > > 	kcb = get_kprobe_ctlblk();
> >> >> > > > 	if (kprobe_running()) {
> >> >> > > > 		kprobes_inc_nmissed_count(p);
> >> >> > > > 	} else {
> >> >> > > > 		unsigned long orig_ip = regs->ip;
> >> >> > > > 		/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
> >> >> > > > 		regs->ip = ip + sizeof(kprobe_opcode_t);
> >> >> > > > 
> >> >> > > > 		/* To emulate trap based kprobes, preempt_disable here */
> >> >> > > > 		preempt_disable();
> >> >> > > > 		__this_cpu_write(current_kprobe, p);
> >> >> > > > 		kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> >> >> > > > 		if (!p->pre_handler || !p->pre_handler(p, regs)) {
> >> >> > > > 			__skip_singlestep(p, regs, kcb, orig_ip);
> >> >> > > > 			preempt_enable_no_resched();  
> >> >> > > 
> >> >> > > This preemption disabling and enabling looks rather strange. Looking at
> >> >> > > git blame, it appears this was added for jprobes. Can we remove it now
> >> >> > > that jprobes is going away?  
> >> >> > 
> >> >> > No, that is not for jprobes but for compatibility with kprobe's user
> >> >> > handler. Since this transformation is done silently, user can not
> >> >> > change their handler for ftrace case. So we need to keep this condition
> >> >> > same as original kprobes.
> >> >> > 
> >> >> > And anyway, for using smp_processor_id() for accessing per-cpu,
> >> >> > we should disable preemption, correct?
> >> >> 
> >> >> But as stated at the start of the function:
> >> >> 
> >> >>  /* Preempt is disabled by ftrace */
> >> > 
> >> > Ah, yes. So this is only for the jprobes.
> >> > 
> >> >> 
> >> >> 
> >> >> The reason I ask, is that we have for this function:
> >> >> 
> >> >> 		/* To emulate trap based kprobes, preempt_disable here */
> >> >> 		preempt_disable();
> >> >> 		__this_cpu_write(current_kprobe, p);
> >> >> 		kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> >> >> 		if (!p->pre_handler || !p->pre_handler(p, regs)) {
> >> >> 			__skip_singlestep(p, regs, kcb, orig_ip);
> >> >> 			preempt_enable_no_resched();
> >> >> 		}
> >> >> 
> >> >> And in arch/x86/kernel/kprobes/core.c we have:
> >> >> 
> >> >> 	preempt_disable();
> >> >> 
> >> >> 	kcb = get_kprobe_ctlblk();
> >> >> 	p = get_kprobe(addr);
> >> >> 
> >> >> 	if (p) {
> >> >> 		if (kprobe_running()) {
> >> >> 			if (reenter_kprobe(p, regs, kcb))
> >> >> 				return 1;
> >> >> 		} else {
> >> >> 			set_current_kprobe(p, regs, kcb);
> >> >> 			kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> >> >> 
> >> >> 			/*
> >> >> 			 * If we have no pre-handler or it returned 0, we
> >> >> 			 * continue with normal processing.  If we have a
> >> >> 			 * pre-handler and it returned non-zero, it prepped
> >> >> 			 * for calling the break_handler below on re-entry
> >> >> 			 * for jprobe processing, so get out doing nothing
> >> >> 			 * more here.
> >> >> 			 */
> >> >> 			if (!p->pre_handler || !p->pre_handler(p, regs))
> >> >> 				setup_singlestep(p, regs, kcb, 0);
> >> >> 			return 1;
> >> >> 
> >> >> 
> >> >> Which is why I thought it was for jprobes. I'm a bit confused about
> >> >> where preemption is enabled again.
> >> > 
> >> > You're right. So I would like to remove it with x86 jprobe support
> >> > code to avoid inconsistency.
> >> 
> >> I didn't understand that. Which code are you planning to remove? Can you 
> >> please elaborate? I thought we still need to disable preemption in the 
> >> ftrace handler.
> > 
> > Yes, kprobe_ftrace_handler itself must be run under preempt disabled
> > because it depends on a per-cpu variable. What I will remove is the
> > redundant preempt disable/enable_noresched (unbalanced) pair in the
> > kprobe_ftrace_handler, and jprobe x86 ports which is no more used.
> 
> Won't that break out-of-tree users depending on returning a non-zero 
> value to handle preemption differently? You seem to have alluded to it 
> earlier in the mail chain above where you said that this is not just for 
> jprobes (though it was added for jprobes as the main use case).

No, all users are in tree already (function override for bpf and error-injection).
And also, for changing execution path by using kprobes, user handler must call
not only preempt_enable(), but also clear current_kprobe per-cpu variable which
is not exported to kmodules.

This means if there is such out-of-tree module, that must change the kernel or
hack the kernel to identify the address of curent_kprobe. If it requires such
a change or hack for the kernel, it is very easy to update the module too.

Thank you,

> 
> - Naveen
> 
> 


-- 
Masami Hiramatsu <mhiramat at kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2018-05-07 14:53 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 12:16 [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features mhiramat
2018-04-25 12:16 ` Masami Hiramatsu
2018-04-25 12:16 ` [PATCH v7 01/16] tracing: probeevent: Cleanup print argument functions mhiramat
2018-04-25 12:16   ` Masami Hiramatsu
2018-04-25 12:17 ` [PATCH v7 02/16] tracing: probeevent: Cleanup argument field definition mhiramat
2018-04-25 12:17   ` Masami Hiramatsu
2018-04-25 12:17 ` [PATCH v7 03/16] tracing: probeevent: Remove NOKPROBE_SYMBOL from print functions mhiramat
2018-04-25 12:17   ` Masami Hiramatsu
2018-04-25 12:18 ` [PATCH v7 04/16] tracing: probeevent: Introduce new argument fetching code mhiramat
2018-04-25 12:18   ` Masami Hiramatsu
2018-04-25 12:18 ` [PATCH v7 05/16] tracing: probeevent: Unify fetch type tables mhiramat
2018-04-25 12:18   ` Masami Hiramatsu
2018-04-25 12:19 ` [PATCH v7 06/16] tracing: probeevent: Return consumed bytes of dynamic area mhiramat
2018-04-25 12:19   ` Masami Hiramatsu
2018-04-25 12:19 ` [PATCH v7 07/16] tracing: probeevent: Append traceprobe_ for exported function mhiramat
2018-04-25 12:19   ` Masami Hiramatsu
2018-04-25 12:19 ` [PATCH v7 08/16] tracing: probeevent: Unify fetch_insn processing common part mhiramat
2018-04-25 12:19   ` Masami Hiramatsu
2018-04-25 12:20 ` [PATCH v7 09/16] tracing: probeevent: Add symbol type mhiramat
2018-04-25 12:20   ` Masami Hiramatsu
2018-04-25 12:20 ` [PATCH v7 10/16] x86: ptrace: Add function argument access API mhiramat
2018-04-25 12:20   ` Masami Hiramatsu
2018-04-25 12:21 ` [PATCH v7 11/16] tracing: probeevent: Add $argN for accessing function args mhiramat
2018-04-25 12:21   ` Masami Hiramatsu
2018-04-25 12:21 ` [PATCH v7 12/16] tracing: probeevent: Add array type support mhiramat
2018-04-25 12:21   ` Masami Hiramatsu
2018-04-25 12:22 ` [PATCH v7 13/16] selftests: ftrace: Add a testcase for symbol type mhiramat
2018-04-25 12:22   ` Masami Hiramatsu
2018-04-25 12:22 ` [PATCH v7 14/16] selftests: ftrace: Add a testcase for $argN with kprobe_event mhiramat
2018-04-25 12:22   ` Masami Hiramatsu
2018-04-25 12:23 ` [PATCH v7 15/16] selftests: ftrace: Add a testcase for array type " mhiramat
2018-04-25 12:23   ` Masami Hiramatsu
2018-04-25 12:23 ` [PATCH v7 16/16] perf-probe: Add array argument support mhiramat
2018-04-25 12:23   ` Masami Hiramatsu
2018-04-27  1:42 ` [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features rostedt
2018-04-27  1:42   ` Steven Rostedt
2018-05-03 22:11 ` rostedt
2018-05-03 22:11   ` Steven Rostedt
2018-05-04 15:48   ` mhiramat
2018-05-04 15:48     ` Masami Hiramatsu
2018-05-04 16:06     ` rostedt
2018-05-04 16:06       ` Steven Rostedt
2018-05-04 17:30       ` naveen.n.rao
2018-05-04 17:30         ` Naveen N. Rao
2018-05-05  2:38       ` mhiramat
2018-05-05  2:38         ` Masami Hiramatsu
2018-05-05  7:46         ` naveen.n.rao
2018-05-05  7:46           ` Naveen N. Rao
2018-05-05 14:32           ` mhiramat
2018-05-05 14:32             ` Masami Hiramatsu
2018-05-07  8:11             ` naveen.n.rao
2018-05-07  8:11               ` Naveen N. Rao
2018-05-07 14:53               ` mhiramat [this message]
2018-05-07 14:53                 ` Masami Hiramatsu
2018-05-08 10:11                 ` naveen.n.rao
2018-05-08 10:11                   ` Naveen N. Rao
2018-05-08 15:02                   ` mhiramat
2018-05-08 15:02                     ` Masami Hiramatsu
2018-05-08 18:01                     ` naveen.n.rao
2018-05-08 18:01                       ` Naveen N. Rao
2018-05-05 15:51         ` mhiramat
2018-05-05 15:51           ` Masami Hiramatsu
2018-05-07 15:30           ` rostedt
2018-05-07 15:30             ` Steven Rostedt
2018-05-08  4:01             ` mhiramat
2018-05-08  4:01               ` Masami Hiramatsu
2018-05-07 15:21         ` rostedt
2018-05-07 15:21           ` Steven Rostedt
2018-06-21 20:16 ` rostedt
2018-06-21 20:16   ` Steven Rostedt
2018-06-22  6:04   ` mhiramat
2018-06-22  6:04     ` Masami Hiramatsu

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=20180507235317.fa04131c603dbe59ef78a829@kernel.org \
    --to=mhiramat@kernel.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).