Re: [RFC PATCH v2 26/31] fprobe: Rewrite fprobe on function-graph tracer

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

 



On Fri, 10 Nov 2023 20:44:22 -0500
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Fri, 10 Nov 2023 16:17:39 +0900
> Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote:
> 
> > > +	used = 0;
> > > +	hlist_for_each_entry_from_rcu(node, hlist) {
> > > +		if (node->addr != func)
> > > +			break;
> > > +		fp = READ_ONCE(node->fp);
> > > +		if (!fp || fprobe_disabled(fp))
> > > +			continue;
> > > +
> > > +		if (fprobe_shared_with_kprobes(fp))
> > > +			ret = __fprobe_kprobe_handler(func, ret_ip,
> > > +					fp, fregs, fgraph_data + used);
> > > +		else
> > > +			ret = __fprobe_handler(func, ret_ip, fp,
> > > +					fregs, fgraph_data + used);  
> > 
> > 
> > Since the fgraph callback is under rcu-locked but not preempt-disabled,
> 
> rcu-locked? The only rcu-locked is task rcu.

Hmm, it might be my misread. But I don't get any warning from
find_first_fprobe_node(), which uses hlist_for_each_entry_rcu()
so isn't it rcu locked?

> 
> > fprobe unittest fails. I need to add preempt_disable_notrace() and
> > preempt_enable_notrace() around this. Note that kprobe_busy_begin()/end()
> > also access to per-cpu variable, so it requires to disable preemption.
> 
> 
> Just around the __fprobe_*handler()? Or the loop?

Just around the __fprobe*handler().

Thank you,


> 
> -- Steve


-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux