On Tue, 7 May 2024 23:08:35 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Add ftrace_regs definition for x86_64 in the ftrace header to
> clarify what register will be accessible from ftrace_regs.
>
> Signed-off-by: Masami Hiramatsu (Google)
> ---
> Changes
On Tue, 7 May 2024 23:08:12 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> To clarify what will be expected on ftrace_regs, add a comment to the
> architecture independent definition of the ftrace_regs.
>
> Signed-off-by: Masami Hiramatsu (Google)
> Acked-by:
ng to sched_dl class only.
> */
> if (tracing_dl || (wakeup_dl && !dl_task(p)) ||
> - (wakeup_rt && !dl_task(p) && !rt_task(p)) ||
> + (wakeup_rt && !realtime_task(p)) ||
> (!dl_task(p) && (p->prio >= wakeup_prio || p->prio >=
> current->prio)))
> return;
>
Reviewed-by: Steven Rostedt (Google)
From: "Steven Rostedt (Google)"
The change to update the permissions of the eventfs_inode had the
misconception that using the tracefs_inode would find all the
eventfs_inodes that have been updated and reset them on remount.
The problem with this approach is that the eventfs_inodes
From: "Steven Rostedt (Google)"
When the inode is being dropped from the dentry, the TRACEFS_EVENT_INODE
flag needs to be cleared to prevent a remount from calling
eventfs_remount() on the tracefs_inode private data. There's a race
between the inode is dropped (and the dentry freed
From: "Steven Rostedt (Google)"
When a remount happens, if a gid or uid is specified update the inodes to
have the same gid and uid. This will allow the simplification of the
permissions logic for the dynamically created files and directories.
Cc: sta...@vger.kernel.org
Fixes: baa
From: "Steven Rostedt (Google)"
The directories require unique inode numbers but all the eventfs files
have the same inode number. Prevent the directories from having the same
inode numbers as the files as that can confuse some tooling.
Cc: sta...@vger.kernel.org
Fixes: 834bf76add3e6
It should be done in the
drop_inode callback.
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
eventfs/urgent
Head SHA1: 41b7db11bcac4638fa489c58d35e7d2146b665ab
Steven Rostedt (Google) (4):
eventfs: Keep the directories from having the same inode number as files
On Wed, 22 May 2024 12:45:04 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The iput callback was added because the remount could call into the
> eventfs code and touch the ei->entry_attrs array, which could have been
> freed when an eve
From: "Steven Rostedt (Google)"
The iput callback was added because the remount could call into the
eventfs code and touch the ei->entry_attrs array, which could have been
freed when an eventfs directory is freed (via a synthetic event). But the
entry_attrs was freed incorrectly a
On Tue, 21 May 2024 09:11:08 -0600
Shuah Khan wrote:
> Any thoughts on this patch?
Sorry, this one fell through the cracks. Daniel Bristot has been
maintaining his tools and I thought this was one of his changes.
I'll take a look at it.
-- Steve
On Mon, 20 May 2024 15:02:26 +0800
"Ubisectech Sirius" wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
>
> Stack dump:
> UBSAN:
On Fri, 17 May 2024 15:40:08 +0200
Petr Pavlu wrote:
> The reader code in rb_get_reader_page() swaps a new reader page into the
> ring buffer by doing cmpxchg on old->list.prev->next to point it to the
> new page. Following that, if the operation is successful,
> old->list.next->prev gets
On Fri, 17 May 2024 10:36:37 -0700
Guenter Roeck wrote:
> Building csky:allmodconfig (and others) ... failed
> --
> Error log:
> In file included from include/trace/trace_events.h:419,
> from include/trace/define_trace.h:102,
> from
On Fri, 17 May 2024 10:08:51 +0300
Jani Nikula wrote:
> On Thu, 16 May 2024, Steven Rostedt wrote:
> > There's over 700 users of __assign_str() and because coccinelle does not
> > handle the TRACE_EVENT() macro I ended up using the following sed script:
> >
> >
From: "Steven Rostedt (Google)"
The sub-buffer pages are held in an unsigned long array, and when it is
passed to virt_to_page() a cast is needed.
Link: https://lore.kernel.org/all/20240515124808.06279...@canb.auug.org.au/
Fixes: 117c39200d9d ("ring-buffer: Introducing ring
On Fri, 10 May 2024 12:03:12 +0100
Vincent Donnefort wrote:
> > I'm not particularly happy about us calling vm_insert_pages with NULL
> > pointers stored in pages.
> >
> > Should we instead do
> >
> > if (WARN_ON_ONCE(s >= nr_subbufs)) {
> > err = -EINVAL;
> > goto out;
> > }
> >
> >
On Tue, 30 Apr 2024 12:13:51 +0100
Vincent Donnefort wrote:
> +#ifdef CONFIG_MMU
> +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> + struct vm_area_struct *vma)
> +{
> + unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
> +
by: xu xin
> Reviewed-by: Yunkai Zhang
> Cc: Yang Yang
> Cc: Liu Chun
> Cc: Xuexin Jiang
> ---
From just a tracing point of view:
Reviewed-by: Steven Rostedt (Google)
-- Steve
| 10 --
> 2 files changed, 1 insertion(+), 10 deletions(-)
Reviewed-by: Steven Rostedt (Google)
-- Steve
Trampolines can only be created if modules are supported */
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
Acked-by: Steven Rostedt (Google)
-- Steve
On Sat, 4 May 2024 13:35:26 +
"Dr. David Alan Gilbert" wrote:
> Hi,
> I've just posted a patch 'ftrace: Remove unused list 'ftrace_direct_funcs''
> that clears out some old code, but while at it I noticed the global
> 'ftrace_direct_func_count'.
>
> As far as I can tell, it's never
On Thu, 2 May 2024 16:13:59 -0700
"Paul E. McKenney" wrote:
> Very good, and thank you!
>
> I will drop it from RCU as soon as it shows up in either -next or in
> mainline.
Sounds good.
I'm currently working on updates to get into -rc7 and plan to add my next
work on top of that (I know, I
On Thu, 2 May 2024 15:58:53 -0700
Beau Belgrave wrote:
> It's not an issue on the matching/logic. However, you do get an extra
> byte alloc (which doesn't bother me in this edge case).
Figured as much, but since there was no mention of it, I decided to bring
it up.
I'll take this as-is then.
> > Thank you,
> >
> > > [1]
> > > https://lore.kernel.org/all/cover.1710877680.git@cloudflare.com/
> > >
> > > Reported-by: Jakub Kicinski
> > > Reported-by: Alexei Starovoitov
> > > Reported-by: Chris Mason
> > >
On Tue, 23 Apr 2024 16:23:37 +
Beau Belgrave wrote:
> When the ABI was updated to prevent same name w/different args, it
> missed an important corner case when fields don't end with a space.
> Typically, space is used for fields to help separate them, like
> "u8 field1; u8 field2". If no
On Wed, 17 Apr 2024 11:28:30 +0800
Zheng Yejian wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index da1710499698..e05d3e3dc06a 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1581,7 +1581,7 @@ static struct dyn_ftrace *lookup_rec(unsigned long
>
From: "Steven Rostedt (Google)"
The events directory gets its permissions from the root inode. But this
can cause an inconsistency if the instances directory changes its
permissions, as the permissions of the created directories under it should
inherit the permissions of the instances
From: "Steven Rostedt (Google)"
Treat the events directory the same as other directories when it comes to
permissions. The events directory was considered different because it's
dentry is persistent, whereas the other directory dentries are created
when accessed. But the way tracefs no
From: "Steven Rostedt (Google)"
There's an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode's permission if they were never set by the user. If the user
sets the permissions, then a f
From: "Steven Rostedt (Google)"
The toplevel events directory is really no different than the events
directory of instances. Having the two be different caused
inconsistencies and made it harder to fix the permissions bugs.
Make all events directories act the same.
Cc: sta...@vger.
From: "Steven Rostedt (Google)"
The freeing of eventfs_inode via a kfree_rcu() callback. But the content
of the eventfs_inode was being freed after the last kref. This is
dangerous, as changes are being made that can access the content of an
eventfs_inode from an RCU loop.
Instea
From: "Steven Rostedt (Google)"
If the instances directory's permissions were never change, then have it
and its children use the mount point permissions as the default.
Currently, the permissions of instance directories are determined by the
instance directory's permissi
that the
iteration of the list only needs to be protected by rcu_read_lock().
Steven Rostedt (Google) (6):
eventfs: Free all of the eventfs_inode after RCU
tracefs: Reset permissions on remount if permissions are options
tracefs: Still use mount point as default permissions for instances
On Thu, 02 May 2024 11:15:48 -0400
Steven Rostedt wrote:
> +/*
> + * On a remount of tracefs, if UID or GID options are set, then
> + * the mount point inode permissions should be used.
> + * Reset the saved permission flags appropriately.
> + */
> +void eventfs_remount(struct
From: "Steven Rostedt (Google)"
The events directory gets its permissions from the root inode. But this
can cause an inconsistency if the instances directory changes its
permissions, as the permissions of the created directories under it should
inherit the permissions of the instances
From: "Steven Rostedt (Google)"
Treat the events directory the same as other directories when it comes to
permissions. The events directory was considered different because it's
dentry is persistent, whereas the other directory dentries are created
when accessed. But the way tracefs no
the node
from the link list, and free the node via call_rcu() so that the
iteration of the list only needs to be protected by rcu_read_lock().
Steven Rostedt (Google) (5):
tracefs: Reset permissions on remount if permissions are options
tracefs: Still use mount point as default
From: "Steven Rostedt (Google)"
If the instances directory's permissions were never change, then have it
and its children use the mount point permissions as the default.
Currently, the permissions of instance directories are determined by the
instance directory's permissi
From: "Steven Rostedt (Google)"
The toplevel events directory is really no different than the events
directory of instances. Having the two be different caused
inconsistencies and made it harder to fix the permissions bugs.
Make all events directories act the same.
Cc: sta...@vger.
From: "Steven Rostedt (Google)"
There's an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode's permission if they were never set by the user. If the user
sets the permissions, then a f
On Thu, 2 May 2024 06:49:18 +
Tze-nan Wu (吳澤南) wrote:
> Good news, this patch works, the test has passed, no more Kasan report
> in my environment.
Great to hear!
>
> my environment:
> arm64 + kasan + swtag based kasan + kernel-6.6.18
>
> Really appreciate, and learn a lot from the
On Thu, 2 May 2024 14:38:32 +0100
Vincent Donnefort wrote:
> > > + while (s < nr_subbufs && p < nr_pages) {
> > > + struct page *page = virt_to_page(cpu_buffer->subbuf_ids[s]);
> > > + int off = 0;
> > > +
> > > + for (; off < (1 << (subbuf_order)); off++, page++) {
> > >
On Wed, 1 May 2024 23:56:26 +0900
Masami Hiramatsu (Google) wrote:
> Looks good to me.
>
> Reviewed-by: Masami Hiramatsu (Google)
Thanks Masami,
Although Tze-nan pointed out a issue with this patch.
I just published v2, can you review that one too?
Thanks,
-- Steve
From: "Steven Rostedt (Google)"
Synthetic events create and destroy tracefs files when they are created
and removed. The tracing subsystem has its own file descriptor
representing the state of the events attached to the tracefs files.
There's a race between the eventfs files and
On Thu, 2 May 2024 03:10:24 +
Tze-nan Wu (吳澤南) wrote:
> >
> Sorry for my late reply, I'm testing the patch on my machine now.
> Test will be done in four hours.
>
> There's something I'm worrying about in the patch,
> what I'm worrying about is commented in the code below.
>
>
From: "Steven Rostedt (Google)"
The events directory gets its permissions from the root inode. But this
can cause an inconsistency if the instances directory changes its
permissions, as the permissions of the created directories under it should
inherit the permissions of the instances
From: "Steven Rostedt (Google)"
Treat the events directory the same as other directories when it comes to
permissions. The events directory was considered different because it's
dentry is persistent, whereas the other directory dentries are created
when accessed. But the way tracefs no
From: "Steven Rostedt (Google)"
The toplevel events directory is really no different than the events
directory of instances. Having the two be different caused
inconsistencies and made it harder to fix the permissions bugs.
Make all events directories act the same.
Cc: sta...@vger.
From: "Steven Rostedt (Google)"
If the instances directory's permissions were never change, then have it
and its children use the mount point permissions as the default.
Currently, the permissions of instance directories are determined by the
instance directory's permissi
.
Steven Rostedt (Google) (5):
tracefs: Reset permissions on remount if permissions are options
tracefs: Still use mount point as default permissions for instances
eventfs: Do not differentiate the toplevel events directory
eventfs: Do not treat events directory different than
From: "Steven Rostedt (Google)"
There's an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode's permission if they were never set by the user. If the user
sets the permissions, then a f
From: "Steven Rostedt (Google)"
Synthetic events create and destroy tracefs files when they are created
and removed. The tracing subsystem has its own file descriptor
representing the state of the events attached to the tracefs files.
There's a race between the eventfs files and
On Sun, 28 Apr 2024 20:28:37 -0400
Steven Rostedt wrote:
> > Looking for any suggestion or solution, appreciate.
>
> Yeah, I do not think eventfs should be involved in this. It needs to be
> protected at a higher level (in the synthetic/dynamic event code).
>
> I'm
On Fri, 26 Apr 2024 15:34:08 +0800
Tze-nan wu wrote:
> "tracing_event_file" is at the risk of use-after-free due to the race of
> two functions "tracing_open_file_tr" and "synth_event_release".
> Specifically, it could be freed by synth_event_release before
> tracing_open_file_tr has the
On Thu, 25 Apr 2024 13:31:53 -0700
Andrii Nakryiko wrote:
I'm just coming back from Japan (work and then a vacation), and
catching up on my email during the 6 hour layover in Detroit.
> Hey Masami,
>
> I can't really review most of that code as I'm completely unfamiliar
> with all those inner
On Tue, 23 Apr 2024 12:04:15 -0400
"Liam R. Howlett" wrote:
> > Nit: For all labels, please add a space before them. Otherwise, diffs will
> > show "unlock" as the function and not "ring_buffer_map", making it harder
> > to find where the change is.
> >
>
> Isn't the inclusion of a space
On Sat, 20 Apr 2024 11:50:29 +0800
"Bang Li" wrote:
> Thank you for your explanation, let me understand this. How about
> replacing ftrace_disabled with unlike(ftrace_disabled)?
Why? They are slow paths. No need to optimize them.
-- Steve
On Mon, 15 Apr 2024 21:50:20 +0900
"Masami Hiramatsu (Google)" wrote:
> @@ -27,23 +28,157 @@
>
> #define FGRAPH_RET_SIZE sizeof(struct ftrace_ret_stack)
> #define FGRAPH_RET_INDEX DIV_ROUND_UP(FGRAPH_RET_SIZE, sizeof(long))
> +
> +/*
> + * On entry to a function (via function_graph_enter()),
On Fri, 19 Apr 2024 16:00:20 +0800
Jason Xing wrote:
> If other experts see this thread, please help me. I would appreciate
> it. I have strong interests and feel strong responsibility to
> implement something like this patch series. It can be very useful!!
I'm not a networking expert, but as
On Fri, 19 Apr 2024 22:38:44 +0800
"Bang Li" wrote:
> Use the existing function ftrace_is_dead to replace the variable to make
> the code clearer.
>
> Signed-off-by: Bang Li
> ---
> kernel/trace/ftrace.c | 46 +--
> 1 file changed, 23 insertions(+), 23
d new flag to skip timestamp recording.
> >
> > Overview
> >
> > This series does major 2 changes, enable multiple function-graphs on
> > the ftrace (e.g. allow function-graph on sub instances) and rewrite the
> > fprobe on this function-graph.
> >
On Thu, 18 Apr 2024 09:55:55 +0300
Mike Rapoport wrote:
Hi Mike,
Thanks for doing this review!
> > +/**
> > + * struct trace_buffer_meta - Ring-buffer Meta-page description
> > + * @meta_page_size:Size of this meta-page.
> > + * @meta_struct_len: Size of this structure.
> > + *
On Mon, 15 Apr 2024 18:40:23 +0900
"Masami Hiramatsu (Google)" wrote:
> Check the number of probe target symbols in the target module when
> the module is loaded. If the probe is not on the unique name symbols
> in the module, it will be rejected at that point.
>
> Note that the symbol which
() to convert it to its value:
(((REC->path_dir) == 1) ? "->" : "<-")
So that user space tools, such as perf and trace-cmd, can parse it
correctly.
Reported-by: Luca Ceresoli
Fixes: 6e588a0d839b5 ("ASoC: dapm: Consolidate path trace events")
Signed-off-by:
On Tue, 16 Apr 2024 04:08:46 +0200
Luca Ceresoli wrote:
> Thanks for the insight. I'm definitely trying to fix this based on your
> hint as soon as I get my hand on a board.
I have a patch I forgot to send out. Let me do that now.
-- Steve
On Mon, 18 Mar 2024 16:43:07 +0100
Luca Ceresoli wrote:
> However the arrows are still reversed.
This requires a kernel change. The problem is that the print fmt has:
print fmt: "%c%s %s %s %s %s", (int) REC->path_node && (int) REC->path_connect
? '*' : ' ', __get_str(wname),
On Sat, 13 Apr 2024 12:53:38 +0200
Peter Zijlstra wrote:
> On Fri, Apr 12, 2024 at 09:37:24AM -0700, Beau Belgrave wrote:
>
> > > Anyway, since we typically run stuff from NMI context, accessing user
> > > data is 'interesting'. As such I would really like to make this work
> > > depend on the
On Thu, 11 Apr 2024 08:15:05 -0700
Kees Cook wrote:
> This looks good to me. If tracing wants to take it:
>
> Acked-by: Kees Cook
>
> If not, I can take it in my tree if I get a tracing Ack. :)
You can take it.
Acked-by: Steven Rostedt (Google)
-- Steve
From: "Steven Rostedt (Google)"
For a persistent ring buffer that is saved across boots, if function
tracing was performed in the previous boot, it only saves the address of
the functions and uses "%pS" to print their names. But the current boot,
those functions may be in
From: "Steven Rostedt (Google)"
Use the saved text_delta and data_delta of a persistent memory mapped ring
buffer that was saved from a previous boot, and use the delta in the trace
event print output so that strings and functions show up normally.
That is, for an event like tra
From: "Steven Rostedt (Google)"
If an instance is mapped to memory on boot up, create a new file called
"last_boot_info" that will hold information that can be used to properly
parse the raw data in the ring buffer.
It will export the delta of the addresses for tex
From: "Steven Rostedt (Google)"
When a ring buffer is mapped to a specific address, save the address of a
text function and some data. This will be used to determine the delta
between the last boot and the current boot for pointers to functions as
well as to data.
Signed-off-by: Stev
From: "Steven Rostedt (Google)"
Make sure all the events in each of the sub-buffers that were mapped in a
memory region are valid. This moves the code that walks the buffers for
time-stamp validation out of the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS
ifdef block and is used t
From: "Steven Rostedt (Google)"
Add a test against the ring buffer memory range to see if it has valid
data. The ring_buffer_meta structure is given a new field called
"first_buffer" which holds the address of the first sub-buffer. This is
used to both determine if the ot
From: "Steven Rostedt (Google)"
Add a buffer_meta per-cpu file for the trace instance that is mapped to
boot memory. This shows the current meta-data and can be used by user
space tools to record off the current mappings to help reconstruct the
ring buffer after a reboot.
It does not
From: "Steven Rostedt (Google)"
Allow for creating a new instance by passing in an address and size to map
the ring buffer for the instance to.
This will allow features like a pstore memory mapped region to be used for
an tracing instance ring buffer that can be retrieved fro
From: "Steven Rostedt (Google)"
Populate the ring_buffer_meta array. It holds the pointer to the
head_buffer (next to read), the commit_buffer (next to write) the size of
the sub-buffers, number of sub-buffers and an array that keeps track of
the order of the sub-buffers.
This i
.
This is no longer a POC as it seems to be working as expected.
This is based on top of Vincent Donnefort's ring buffer user space mapping code:
https://lore.kernel.org/linux-trace-kernel/20240406173649.3210836-1-vdonnef...@google.com/
Enjoy...
Steven Rostedt (Google) (11):
ring-
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user space memory mapped buffers,
allow it to use the "mapped" field of the ring_buffer_per_cpu structure
without having the
From: "Steven Rostedt (Google)"
In preparation to allowing the trace ring buffer to be allocated in a
range of memory that is persistent across reboots, add
ring_buffer_alloc_range(). It takes a contiguous range of memory and will
split it up evening for the per CPU ring buffers.
On Wed, 10 Apr 2024 13:07:20 -0400
Chuck Lever wrote:
> Well I guess I could test it for you. I'll take it for nfsd v6.9-rc.
Thanks!
-- Steve
Hi Andrew, et.al.
Linus said it's a hard requirement that this code gets an Acked-by (or
Reviewed-by) from the memory sub-maintainers before he will accept it.
He was upset that we faulted in pages one at a time instead of mapping it
in one go:
On Sat, 6 Apr 2024 18:36:46 +0100
Vincent Donnefort wrote:
> +int ring_buffer_map(struct trace_buffer *buffer, int cpu,
> + struct vm_area_struct *vma)
> +{
> + struct ring_buffer_per_cpu *cpu_buffer;
> + unsigned long flags, *subbuf_ids;
> + int err = 0;
> +
> +
Hi Vincent,
Thanks for sending this. Nit: Subject should start with a capital:
ring-buffer: Allocate sub-buffers with __GFP_COMP
-- Steve
On Sat, 6 Apr 2024 18:36:45 +0100
Vincent Donnefort wrote:
> In preparation for the ring-buffer memory mapping, allocate compound
> pages for the
On Wed, 10 Apr 2024 12:38:53 -0400
Chuck Lever wrote:
> On Wed, Apr 10, 2024 at 12:38:13PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > The rpcgss_context trace event acceptor field is a dynamically sized
> > str
From: "Steven Rostedt (Google)"
The rpcgss_context trace event acceptor field is a dynamically sized
string that records the "data" parameter. But this parameter is also
dependent on the "len" field to determine the size of the data.
It needs to use __string_len()
On Mon, 1 Apr 2024 20:55:43 +0800
Zheng Yejian wrote:
> KASAN reports a bug:
>
> BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
> Read of size 8 at addr 888141d40010 by task insmod/424
> CPU: 8 PID: 424 Comm: insmod Tainted: GW 6.9.0-rc2+ #213
> [...]
>
On Wed, 10 Apr 2024 08:44:00 +0900
Masami Hiramatsu (Google) wrote:
> Looks good to me.
>
> Acked-by: Masami Hiramatsu (Google)
Thanks.
>
> BTW, isn't this a real bugfix, because the page_touched can be
> bigger than nr_pages without this fix?
Yes, I simply forgot to add the Cc stable.
--
From: "Steven Rostedt (Google)"
The "buffer_percent" logic that is used by the ring buffer splice code to
only wake up the tasks when there's no data after the buffer is filled to
the percentage of the "buffer_percent" file is dependent on three
variables tha
> +#define FNe2(reason) { SKB_DROP_REASON_##reason, #reason }
Anyway, from a tracing point of view, as it looks like it would work
(I haven't tested it).
Reviewed-by: Steven Rostedt (Google)
-- Steve
On Mon, 8 Apr 2024 16:58:17 +0200
Michal Koutný wrote:
> @@ -294,7 +295,7 @@ static void __trace_find_cmdline(int pid, char comm[])
> return;
> }
>
> - tpid = pid & (PID_MAX_DEFAULT - 1);
> + tpid = pid % PID_MAP_SIZE;
Does that compile to the same? This is a fast
On Mon, 8 Apr 2024 11:01:54 +0200
Marco Elver wrote:
> Add "new_exec" tracepoint, which is run right after the point of no
> return but before the current task assumes its new exec identity.
>
> Unlike the tracepoint "sched_process_exec", the "new_exec" tracepoint
> runs before flushing the
On Wed, 3 Apr 2024 11:53:14 -0700
"Paul E. McKenney" wrote:
> @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> ftrace_hash *hash, unsigned long
> }
> }
>
> +static void register_ftrace_direct_cb(struct rcu_head *rhp)
> +{
> + struct ftrace_hash *fhp =
On Wed, 3 Apr 2024 15:39:44 +0100
Vincent Donnefort wrote:
> > Do you plan on sending out a v20 series?
>
> Of course, let me spin that this week! Got also few typos to fix in the doc
> and
> I believe an include missing for riscv.
No rush, I'll be on PTO until next Tuesday, and will not
On Fri, 29 Mar 2024 14:40:55 -0400
Steven Rostedt wrote:
> > +static vm_fault_t tracing_buffers_mmap_fault(struct vm_fault *vmf)
> > +{
> > + return VM_FAULT_SIGBUS;
> > +}
>
> If this is all it does, I don't believe it's needed.
>
> > +
> > +#
On Tue, 2 Apr 2024 22:21:00 -0700
Andrii Nakryiko wrote:
> > I just checked our fleet-wide production data for the last 24 hours.
> > Within the kprobe/kretprobe code path (ftrace_trampoline and
> > everything called from it), rcu_is_watching (both calls, see below)
> > cause 0.484% CPU cycles
On Tue, 2 Apr 2024 21:00:19 -0700
Andrii Nakryiko wrote:
> I just noticed another rcu_is_watching() call, in rethook_try_get(),
> which seems to be a similar and complementary validation check to the
> one we are putting under CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING option
> in this patch. It
On Wed, 3 Apr 2024 09:40:48 +0900
Masami Hiramatsu (Google) wrote:
> OK, for me, this last sentence is preferred for the help message. That
> explains
> what this is for.
>
> All callbacks that attach to the function tracing have some sort
> of protection against recursion.
On Mon, 1 Apr 2024 19:29:46 -0700
Andrii Nakryiko wrote:
> On Mon, Apr 1, 2024 at 5:38 PM Masami Hiramatsu wrote:
> >
> > On Mon, 1 Apr 2024 12:09:18 -0400
> > Steven Rostedt wrote:
> >
> > > On Mon, 1 Apr 2024 20:25:52 +0900
> > > Masami Hirama
1 - 100 of 34148 matches
Mail list logo
