On Fri, 19 Jan 2024 10:52:43 -0500
Steven Rostedt wrote:
> On Fri, 19 Jan 2024 23:43:56 +0900
> Masami Hiramatsu (Google) wrote:
>
> > Thanks for your proposal!
> >
> > Generically, I think this type of hack is not good for the tracing
> > because there are already some ways to do that. e.g.
Hi Ye,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.7 next-20240119]
[cannot apply to rostedt-trace/for-next rostedt-trace/for-next-urgent]
[If your patch is applied to the wrong git tree, kindly drop us a note
On 2024/1/19 22:43, Masami Hiramatsu (Google) wrote:
On Fri, 19 Jan 2024 09:38:45 +0800
Ye Bin wrote:
During fault locating, the file name needs to be printed based on the
dentry/file address. The offset needs to be calculated each time, which
is troublesome. Similar to printk, kprobe
On 2024-01-19 16:42, Steven Rostedt wrote:
On Fri, 19 Jan 2024 15:56:21 -0500
Mathieu Desnoyers wrote:
So when an overflow happens, you just insert a timestamp, and then events
after that is based on that?
No. Let's use an example to show how it works.
For reference, LTTng uses 5-bit for
Hi Ye,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.7 next-20240119]
[cannot apply to rostedt-trace/for-next rostedt-trace/for-next-urgent]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Fri, 19 Jan 2024 15:56:21 -0500
Mathieu Desnoyers wrote:
> > So when an overflow happens, you just insert a timestamp, and then events
> > after that is based on that?
>
> No. Let's use an example to show how it works.
>
> For reference, LTTng uses 5-bit for event ID and 27-bit for
On 2024-01-19 10:37, Steven Rostedt wrote:
On Fri, 19 Jan 2024 09:40:27 -0500
Mathieu Desnoyers wrote:
On 2024-01-18 18:12, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
[...]
Although, it does not get rid of the double time stamps (before_stamp and
write_stamp), using
From: "Steven Rostedt (Google)"
As the ring buffer never had a cmpxchg loop until the reserving logic
added one, add a statistic on how many times it happens. This can be used
to make sure there's not any issues because the writer is retrying.
~# cat /sys/kernel/tracing/per_cpu/cpu0/stats
On Fri, 19 Jan 2024 23:43:56 +0900
Masami Hiramatsu (Google) wrote:
> Thanks for your proposal!
>
> Generically, I think this type of hack is not good for the tracing
> because there are already some ways to do that. e.g.
> - Use perf probe to specify dentry->name:string or file->name:string
On Fri, 19 Jan 2024 09:40:27 -0500
Mathieu Desnoyers wrote:
> On 2024-01-18 18:12, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Instead of using local_add_return() to reserve the ring buffer data,
> > Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify
On Thu, Jan 18, 2024 at 10:22:05AM +0800, Kunwu Chan wrote:
> Hi Simon,
>
> Thanks for your reply.
>
> On 2024/1/17 17:29, Simon Horman wrote:
> > On Wed, Jan 17, 2024 at 03:20:45PM +0800, Kunwu Chan wrote:
> > > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> > > to
On Fri, 19 Jan 2024 09:38:46 +0800
Ye Bin wrote:
> Similar to '%pd' for printk, use 'pd' for print struct dentry's name.
No, please use '%pd' as a type instead.
>
> Signed-off-by: Ye Bin
> ---
> kernel/trace/trace_probe.c | 38 ++
> 1 file changed, 38
On 2024-01-18 18:12, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Instead of using local_add_return() to reserve the ring buffer data,
Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify the
reservation with the time keeping code.
I admire the effort of trying to
On Fri, 19 Jan 2024 09:38:45 +0800
Ye Bin wrote:
> During fault locating, the file name needs to be printed based on the
> dentry/file address. The offset needs to be calculated each time, which
> is troublesome. Similar to printk, kprobe supports printing file names
> for dentry/file addresses.
On Thu, Jan 18, 2024 at 02:18:42AM +, Chen Zhongjin wrote:
> There is a deadlock scenario in kprobe_optimizer():
>
> pid A pid B pid C
> kprobe_optimizer()do_exit() perf_kprobe_init()
> mutex_lock(_mutex)
On Wed, 17 Jan 2024 21:26:46 -0500
Steven Rostedt wrote:
> On Thu, 18 Jan 2024 02:18:42 +
> Chen Zhongjin wrote:
>
> > There is a deadlock scenario in kprobe_optimizer():
> >
> > pid A pid B pid C
> > kprobe_optimizer() do_exit()
On Thu, Jan 18, 2024 at 06:44:54AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 17, 2024 at 09:26:46PM -0500, Steven Rostedt wrote:
> > On Thu, 18 Jan 2024 02:18:42 +
> > Chen Zhongjin wrote:
> >
> > > There is a deadlock scenario in kprobe_optimizer():
> > >
> > > pid A
17 matches
Mail list logo