Re: [PATCH 0/3] support '%pd' and '%pD' for print file name

2024-01-19 Thread Google
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.

Re: [PATCH 1/3] tracing/probes: support '%pd' type for print struct dentry's name

2024-01-19 Thread kernel test robot
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

Re: [PATCH 0/3] support '%pd' and '%pD' for print file name

2024-01-19 Thread yebin (H)
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

Re: [PATCH] ring-buffer: Simplify reservation with try_cmpxchg() loop

2024-01-19 Thread Mathieu Desnoyers
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

Re: [PATCH 1/3] tracing/probes: support '%pd' type for print struct dentry's name

2024-01-19 Thread kernel test robot
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

Re: [PATCH] ring-buffer: Simplify reservation with try_cmpxchg() loop

2024-01-19 Thread Steven Rostedt
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

Re: [PATCH] ring-buffer: Simplify reservation with try_cmpxchg() loop

2024-01-19 Thread Mathieu Desnoyers
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

[PATCH] ring-buffer: Add writer_loops to stat file

2024-01-19 Thread Steven Rostedt
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

Re: [PATCH 0/3] support '%pd' and '%pD' for print file name

2024-01-19 Thread Steven Rostedt
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

Re: [PATCH] ring-buffer: Simplify reservation with try_cmpxchg() loop

2024-01-19 Thread Steven Rostedt
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

Re: [PATCH net] ipvs: Simplify the allocation of ip_vs_conn slab caches

2024-01-19 Thread Simon Horman
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

Re: [PATCH 1/3] tracing/probes: support '%pd' type for print struct dentry's name

2024-01-19 Thread Google
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

Re: [PATCH] ring-buffer: Simplify reservation with try_cmpxchg() loop

2024-01-19 Thread Mathieu Desnoyers
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

Re: [PATCH 0/3] support '%pd' and '%pD' for print file name

2024-01-19 Thread Google
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.

Re: [PATCH v2] kprobes: Use synchronize_rcu_tasks_rude in kprobe_optimizer

2024-01-19 Thread Paul E. McKenney
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)

Re: [PATCH v2] kprobes: Use synchronize_rcu_tasks_rude in kprobe_optimizer

2024-01-19 Thread Google
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()

Re: [PATCH v2] kprobes: Use synchronize_rcu_tasks_rude in kprobe_optimizer

2024-01-19 Thread Paul E. McKenney
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