Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Masami Hiramatsu wrote:
On Fri, 4 May 2018 12:06:42 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

On Sat, 5 May 2018 00:48:28 +0900
Masami Hiramatsu <mhiramat@xxxxxxxxxx> 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.

Thanks,
Naveen


--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Development]     [Linux USB Development]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux