From: "Steven Rostedt (Google)"
On bugs that have the ring buffer timestamp get out of sync, the config
CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS, that checks for it and if it is
detected it causes a dump of the bad sub buffer.
It shows each event and their timestamp as well as
On Mon, 11 Dec 2023 21:31:34 +0900
Masami Hiramatsu (Google) wrote:
> On Sun, 10 Dec 2023 22:54:47 -0500
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > The snapshot buffer is to mimic the main buffer so that when a snapshot is
>
From: "Steven Rostedt (Google)"
On 32bit machines, the 64 bit timestamps are broken up into 32 bit words
to keep from using local64_cmpxchg(), as that is very expensive on 32 bit
architectures.
On 32 bit architectures, reading these timestamps can happen in a middle
of an update. In
From: "Steven Rostedt (Google)"
The ring buffer timestamps are synchronized by two timestamp placeholders.
One is the "before_stamp" and the other is the "write_stamp" (sometimes
referred to as the "after stamp" but only in the comments. These two
stamps
From: "Steven Rostedt (Google)"
The snapshot buffer is to mimic the main buffer so that when a snapshot is
needed, the snapshot and main buffer are swapped. When the snapshot buffer
is allocated, it is set to the minimal size that the ring buffer may be at
and still functi
From: "Steven Rostedt (Google)"
Reading the ring buffer does a swap of a sub-buffer within the ring buffer
with a empty sub-buffer. This allows the reader to have full access to the
content of the sub-buffer that was swapped out without having to worry
about contention with
On Sun, 10 Dec 2023 12:28:32 -0500
Mathieu Desnoyers wrote:
> > Again, it's not a requirement, it's just an enhancement.
>
> How does this have anything to do with dispensing from testing the
> new behavior ? If the new behavior has a bug that causes it to
> silently truncate the trace marker
On Sun, 10 Dec 2023 11:07:22 -0500
Mathieu Desnoyers wrote:
> > It just allows more to be written in one go.
> >
> > I don't see why the tests need to cover this or detect this change.
>
> If the purpose of this change is to ensure that the entire
> trace marker payload is shown within a
On Sun, 10 Dec 2023 09:26:13 -0500
Mathieu Desnoyers wrote:
> This test has no clue if the record was truncated or not.
>
> It basically repeats the string
>
> "1234567890" until it fills the subbuffer size and pads with
> as needed as trace marker payload, but the grep looks for the
>
On Sun, 10 Dec 2023 09:17:44 -0500
Mathieu Desnoyers wrote:
> On 2023-12-09 22:54, Steven Rostedt wrote:
> [...]
> >
> > Basically, events to the tracing subsystem are limited to just under a
> > PAGE_SIZE, as the ring buffer is split into "sub buffers" of o
On Sun, 10 Dec 2023 09:11:40 -0500
Mathieu Desnoyers wrote:
> On 2023-12-09 17:10, Steven Rostedt wrote:
> [...]
> > <...>-852 [001] . 121.550551:
> > tracing_mark_write[LINE TOO BIG]
> > <...>-852 [001] ..
On Sun, 10 Dec 2023 09:09:06 -0500
Mathieu Desnoyers wrote:
> On 2023-12-09 17:50, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Allow a trace write to be as big as the ring buffer tracing data will
> > allow. Currently, it only allo
From: "Steven Rostedt (Google)"
Because the main buffer and the snapshot buffer need to be the same for
some tracers, otherwise it will fail and disable all tracing, the tracers
need to be stopped while updating the sub buffer sizes so that the tracers
see the main and snapsh
_read_page()
ring_buffer_read_page()
A new API is introduced:
ring_buffer_read_page_data()
Link:
https://lore.kernel.org/linux-trace-devel/20211213094825.61876-6-tz.stoya...@gmail.com
Signed-off-by: Tzvetomir Stoyanov (VMware)
Signed-off-by: Steven Rostedt (Google)
---
include/linux/rin
From: "Steven Rostedt (Google)"
When updating the order of the sub buffers for the main buffer, make sure
that if the snapshot buffer exists, that it gets its order updated as
well.
Signed-off-by: Steven Rostedt (Google)
---
kernel/trace/tr
mir Stoyanov (VMware)
Signed-off-by: Steven Rostedt (Google)
---
include/linux/ring_buffer.h | 4 ++
kernel/trace/ring_buffer.c | 73 +
kernel/trace/trace.c| 48
3 files changed, 125 insertions(+)
diff --git a/include/linux/ring_buff
From: "Steven Rostedt (Google)"
The ring_buffer_subbuf_order_set() was creating ring_buffer_per_cpu
cpu_buffers with the new subbuffers with the updated order, and if they
all successfully were created, then they the ring_buffer's per_cpu buffers
would be freed and replaced by them.
T
From: "Steven Rostedt (Google)"
Now that the ring buffer specifies the size of its sub buffers, they all
need to be the same size. When doing a read, a swap is done with a spare
page. Make sure they are the same size before doing the swap, otherwise
the read will fail.
Signed-off-
fer.
Link:
https://lore.kernel.org/linux-trace-devel/20211213094825.61876-3-tz.stoya...@gmail.com
Signed-off-by: Tzvetomir Stoyanov (VMware)
Signed-off-by: Steven Rostedt (Google)
---
include/linux/ring_buffer.h | 2 +-
kernel/trace/ring_buffer.c | 65 +++
From: "Steven Rostedt (Google)"
Add a self test that will write into the trace buffer with differ trace
sub buffer order sizes.
Signed-off-by: Steven Rostedt (Google)
---
.../ftrace/test.d/00basic/ringbuffer_order.tc | 46 +++
1 file changed, 46 insertions(+)
c
ch sub buffer a size of 8 pages, allowing events to be almost
as big as 8 pages in size (sub buffers do have meta data on them as
well, keeping an event from reaching the same size as a sub buffer).
Steven Rostedt (Google) (9):
ring-buffer: Clear pages on error in ring_buffer_subbuf_order_s
From: "Steven Rostedt (Google)"
As all the subbuffer order (subbuffer sizes) must be the same throughout
the ring buffer, check the order of the buffers that are doing a CPU
buffer swap in ring_buffer_swap_cpu() to make sure they are the same.
If the are not the same, then fail to d
inux-trace-devel/20211213094825.61876-2-tz.stoya...@gmail.com
Signed-off-by: Tzvetomir Stoyanov (VMware)
Signed-off-by: Steven Rostedt (Google)
---
kernel/trace/ring_buffer.c | 60 +++---
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/ke
From: "Steven Rostedt (Google)"
The function ring_buffer_subbuf_order_set() just updated the sub-buffers
to the new size, but this also changes the size of the buffer in doing so.
As the size is determined by nr_pages * subbuf_size. If the subbuf_size is
increased without decreasing th
From: "Steven Rostedt (Google)"
Add to the documentation how to use the buffer_subbuf_order file to change
the size and how it affects what events can be added to the ring buffer.
Signed-off-by: Steven Rostedt (Google)
---
Documentation/trace/ftrace.rst | 27
From: "Steven Rostedt (Google)"
On failure to allocate ring buffer pages, the pointer to the CPU buffer
pages is freed, but the pages that were allocated previously were not.
Make sure they are freed too.
Fixes: TBD ("tracing: Set new size of the ring buffer sub page")
S
race-devel/20211213094825.61876-5-tz.stoya...@gmail.com
Signed-off-by: Tzvetomir Stoyanov (VMware)
Signed-off-by: Steven Rostedt (Google)
---
kernel/trace/ring_buffer.c | 80 ++
1 file changed, 73 insertions(+), 7 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/ke
From: "Steven Rostedt (Google)"
There's no reason to give an arbitrary limit to the size of a raw trace
marker. Just let it be as big as the size that is allowed by the ring
buffer itself.
And there's also no reason to artificially break up the write to
TRACE_BUF_SIZE, as that's not
From: "Steven Rostedt (Google)"
Now that trace_marker can hold more than 1KB string, and can write as much
as the ring buffer can hold, the trace_seq is not big enough to hold
writes:
~# a="1234567890"
~# cnt=4080
~# s=""
~# while [ $cnt -gt 10 ]; do
~# s
From: "Steven Rostedt (Google)"
Allow a trace write to be as big as the ring buffer tracing data will
allow. Currently, it only allows writes of 1KB in size, but there's no
reason that it cannot allow what the ring buffer can hold.
Signed-off-by: Steven Rostedt (Google)
---
[
From: "Steven Rostedt (Google)"
If a large event was added to the ring buffer that is larger than what the
trace_seq can handle, it just drops the output:
~# cat /sys/kernel/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written:
On Sat, 9 Dec 2023 17:01:39 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The maximum ring buffer data size is the maximum size of data that can be
> recorded on the ring buffer. Events must be smaller than the sub buffer
> data size minus
From: "Steven Rostedt (Google)"
The maximum ring buffer data size is the maximum size of data that can be
recorded on the ring buffer. Events must be smaller than the sub buffer
data size minus any meta data. This size is checked before trying to
allocate from the ring buff
On Fri, 8 Dec 2023 18:36:01 +
Beau Belgrave wrote:
> While developing some unrelated features I happened to create a
> trace_event that was more than NAME_MAX (255) characters. When this
> happened the creation worked, but tracefs would hang any task that tried
> to list the directory of the
On Fri, 8 Dec 2023 15:16:10 +0100
Alexander Potapenko wrote:
> On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
> >
> > Architectures use assembly code to initialize ftrace_regs and call
> > ftrace_ops_list_func(). Therefore, from the KMSAN's point of view,
> > ftrace_regs is poisoned
From: "Steven Rostedt (Google)"
On bugs that have the ring buffer timestamp get out of sync, the config
CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS, that checks for it and if it is
detected it causes a dump of the bad sub buffer.
It shows each event and their timestamp as well as
On Thu, 7 Dec 2023 17:19:24 -0500
Mathieu Desnoyers wrote:
> On 2023-12-07 17:16, Steven Rostedt wrote:
>
> [...]
>
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 8d2a4f00eca9..b10deb8a5647 100644
> > --- a/kernel/trace/ring_b
From: "Steven Rostedt (Google)"
On bugs that have the ring buffer timestamp get out of sync, the config
CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS, that checks for it and if it is
detected it causes a dump of the bad sub buffer.
It shows each event and their timestamp as well as
On Wed, 6 Dec 2023 21:12:57 +0530
Krishna chaitanya chundru wrote:
> diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
> index f78aefd2d7a3..6acb85f4c5f8 100644
> --- a/drivers/bus/mhi/host/init.c
> +++ b/drivers/bus/mhi/host/init.c
> @@ -20,6 +20,9 @@
> #include
>
From: "Steven Rostedt (Google)"
There's a race where if an event is discarded from the ring buffer and an
interrupt were to happen at that time and insert an event, the time stamp
is still used from the discarded event as an offset. This can screw up the
timings.
If the even
From: "Steven Rostedt (Google)"
Since 64 bit cmpxchg() is very expensive on 32bit architectures, the
timestamp used by the ring buffer does some interesting tricks to be able
to still have an atomic 64 bit number. It originally just used 60 bits and
broke it up into two 32 bit w
From: "Steven Rostedt (Google)"
A trace instance may only need to enable specific events. As the eventfs
directory of an instance currently creates all events which adds overhead,
allow internal instances to be created with just the events in systems
that they care about. This curr
From: "Steven Rostedt (Google)"
When the ring buffer is being resized, it can cause side effects to the
running tracer. For instance, there's a race with irqsoff tracer that
swaps individual per cpu buffers between the main buffer and the snapshot
buffer. The resize operation modifie
From: "Steven Rostedt (Google)"
It use to be that only the top level instance had a snapshot buffer (for
latency tracers like wakeup and irqsoff). The update of the ring buffer
size would check if the instance was the top level and if so, it would
also update the snapshot buffer a
From: "Steven Rostedt (Google)"
It use to be that only the top level instance had a snapshot buffer (for
latency tracers like wakeup and irqsoff). When stopping a tracer in an
instance would not disable the snapshot buffer. This could have some
unintended consequences if the irqs
with the change log of patch 1.
That patch just needs to be ignored.
Steven Rostedt (Google) (3):
tracing: Always update snapshot buffer size
tracing: Stop current tracer when resizing buffer
tracing: Disable snapshot buffer when stopping instance tracers
kernel/trace
On Tue, 5 Dec 2023 20:39:28 +0100
Eric Dumazet wrote:
> > So, we do not want to add some tracepoint to do some unknow debug.
> > We have a clear goal. debugging is just an incidental capability.
> >
>
> We have powerful mechanisms in the stack already that ordinary (no
> privilege requested)
On Tue, 5 Dec 2023 19:13:09 +0100
Dmytro Maluka wrote:
> On Tue, Nov 28, 2023 at 12:21:17PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > A trace instance may only need to enable specific events. As the eventfs
> > directory
On Tue, 5 Dec 2023 11:52:23 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> It use to be that only the top level instance had a snapshot buffer (for
> latency tracers like wakeup and irqsoff). The update of the ring buffer
> size would check if the i
From: "Steven Rostedt (Google)"
It use to be that only the top level instance had a snapshot buffer (for
latency tracers like wakeup and irqsoff). The update of the ring buffer
size would check if the instance was the top level and if so, it would
also update the snapshot buffer a
On Sun, 3 Dec 2023 10:33:32 +0900
Dominique Martinet wrote:
> > TP_printk("clnt %lu %s(tag = %d)\n%.3x: %16ph\n%.3x: %16ph\n",
> > (unsigned long)__entry->clnt,
> > show_9p_op(__entry->type),
> > __entry->tag, 0,
On Sat, 02 Dec 2023 14:05:24 +0100
Christian Schoenebeck wrote:
> > > --- a/include/trace/events/9p.h
> > > +++ b/include/trace/events/9p.h
> > > @@ -185,7 +185,8 @@ TRACE_EVENT(9p_protocol_dump,
> > > __entry->clnt = clnt;
> > > __entry->type = pdu->id;
> > >
On Fri, 1 Dec 2023 09:25:59 -0800
Justin Chen wrote:
> > It appears the sub instruction at 0x6dd0 correctly accounts for the
> > extra 8 bytes, so the frame pointer is valid. So it is our assumption
> > that there are no gaps between the stack frames is invalid.
>
> Thanks for the assistance.
On Fri, 1 Dec 2023 10:01:33 -0700
Jeffrey Hugo wrote:
> > +DECLARE_EVENT_CLASS(mhi_process_event_ring,
> > +
> > + TP_PROTO(const char *name, void *rp, __le64 ptr,
> > +__le32 dword0, __le32 dword1),
> > +
> > + TP_ARGS(name, rp, ptr, dword0, dword1),
> > +
> > +
On Fri, 1 Dec 2023 15:17:35 +0100
Petr Pavlu wrote:
> Ok, keeping the current approach, my plan for v2 is to prepare the
> following patches:
>
> * Fix for the missing increment+decrement of trace_buffered_event_cnt
> on the current CPU in trace_buffered_event_disable().
>
> Replace
On Wed, 29 Nov 2023 23:58:21 +0900
Masami Hiramatsu (Google) wrote:
> > - Dynamic events had to be specified directly to still allow them to be
> > created.
>
> I have a question about this point. Does this mean the dynamic event files
> will be created in the instance which limits the
From: "Steven Rostedt (Google)"
I was loading a very large trace.dat file into kernelshark when it just
stopped near the end off the load and hung there for a very long time. I
ran it under gdb and hit Ctrl^C when it hit the hang to see what it was
doing and found that it wa
From: "Steven Rostedt (Google)"
A trace instance may only need to enable specific events. As the eventfs
directory of an instance currently creates all events which adds overhead,
allow internal instances to be created with just the events in systems
that they care about. This curr
On Wed, 29 Nov 2023 00:17:38 +0900
Masami Hiramatsu (Google) wrote:
> Hi Steve,
>
> On Mon, 27 Nov 2023 17:41:08 -0500
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > A trace instance may only need to enable specific events.
On Tue, 28 Nov 2023 09:20:29 -0500
Steven Rostedt wrote:
> On Tue, 28 Nov 2023 14:14:29 +0100
> Dmytro Maluka wrote:
>
>
> > This limitation will cause (unrelated) events created by modules that
> > are insmoded after creating the instance to be also added to the
>
On Tue, 28 Nov 2023 14:14:29 +0100
Dmytro Maluka wrote:
> This limitation will cause (unrelated) events created by modules that
> are insmoded after creating the instance to be also added to the
> instance. Why not filter those as well?
I did think of that. But that would be a separate patch.
On Mon, 27 Nov 2023 17:41:08 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> A trace instance may only need to enable specific events. As the eventfs
> directory of an instance currently creates all events which adds overhead,
> allow interna
On Mon, 27 Nov 2023 16:12:48 +0100
Petr Pavlu wrote:
> Make the disable operation in __ftrace_event_enable_disable() use the
> reverse order of the respective enable operation.
>
> This has two minor benefits:
> * Disabling of buffered events via trace_buffered_event_disable() is
> done after
On Mon, 27 Nov 2023 16:12:47 +0100
Petr Pavlu wrote:
> The following warning appears when using buffered events:
> [ 203.556451] WARNING: CPU: 53 PID: 10220 at kernel/trace/ring_buffer.c:3912
> ring_buffer_discard_commit+0x2eb/0x420
Hmm, I don't have a waring on line 3912, do you have extra
On Thu, 23 Nov 2023 12:25:48 +0100
Heiko Carstens wrote:
> So, if it helps (this still happens with Linus' master branch):
>
> create_dir_dentry() is called with a "struct eventfs_inode *ei" (second
> parameter), which points to a data structure where "is_freed" is 1. Then it
> looks like
On Wed, 22 Nov 2023 09:19:25 -0500
Josef Bacik wrote:
> On Tue, Nov 21, 2023 at 06:10:03PM -0500, Steven Rostedt wrote:
> > Mark Rutland reported some crashes from the latest eventfs updates.
> > This fixes most of them.
> >
> > He still has one splat that he can t
arnings when running the ftrace testsuite.
>
> Fix by trusting the architecture-specific assembly code and always
> unpoisoning ftrace_regs in ftrace_ops_list_func.
You must be very trusting to trust architecture-specific assembly code ;-)
Acked-by: Steven Rostedt (Google)
-- Steve
>
On Thu, 12 Oct 2023 16:37:35 -0400
Nick Lowell wrote:
Sorry, I was traveling when this was sent, and I missed it.
> I really appreciate the continued feedback. I was able to reproduce.
> I think I'm understanding better but still need some help.
> I am actually wondering if
On Wed, 22 Nov 2023 19:49:43 +0530
Naresh Kamboju wrote:
> Hi Steven,
>
>
>
> On Tue, 21 Nov 2023 at 02:06, Steven Rostedt wrote:
> >
> > On Thu, 16 Nov 2023 18:00:16 +0530
> > Naresh Kamboju wrote:
> >
> > > Following kernel crash
From: "Steven Rostedt (Google)"
Since the locking of the parent->d_inode has been moved outside the
creation of the files and directories (as it use to be locked via a
conditional), add a WARN_ON_ONCE() to the case that it's not locked.
Signed-off-by: Steven Rostedt (Google)
--
From: "Steven Rostedt (Google)"
The both create_file_dentry() and create_dir_dentry() takes a boolean
parameter "lookup", as on lookup the inode_lock should already be taken,
but for dcache_dir_open_wrapper() it is not taken.
There's no reason that the dcache_dir_open_
Mark Rutland reported some crashes from the latest eventfs updates.
This fixes most of them.
He still has one splat that he can trigger but I can not. Still looking
into that.
Steven Rostedt (Google) (4):
eventfs: Use GFP_NOFS for allocation when eventfs_mutex is held
eventfs: Move
From: "Steven Rostedt (Google)"
If memory reclaim happens, it can reclaim file system pages. The file
system pages from eventfs may take the eventfs_mutex on reclaim. This
means that allocation while holding the eventfs_mutex must not call into
filesystem reclaim. A lockdep splat
From: "Steven Rostedt (Google)"
The eventfs directory is dynamically created via the meta data supplied by
the existing trace events. All files and directories in eventfs has a
parent. Do not allow NULL to be passed into eventfs_start_creating() as
the parent because that should ne
From: "Steven Rostedt (Google)"
The logic to free the eventfs_inode (ei) use to set is_freed and clear the
"dentry" field under the eventfs_mutex. But that changed when a race was
found where the ei->dentry needed to be cleared when the last dput() was
called on it. Bu
From: "Steven Rostedt (Google)"
With the call to simple_recursive_removal() on the entire eventfs sub
system when the directory is removed, it performs the d_invalidate on all
the dentries when it is removed. There's no need to do clean ups when a
dentry is being created while the
se. That's no longer true and there
should not be any warnings when it is true.
Steven Rostedt (Google) (2):
eventfs: Remove expectation that ei->is_freed means ei->dentry == NULL
eventfs: Do not invalidate dentry in create_file/dir_dentry()
On Thu, 16 Nov 2023 18:00:16 +0530
Naresh Kamboju wrote:
> Following kernel crash noticed while running selftests: ftrace on arm64
> Juno-r2
> device running stable-rc linux-6.6.y kernel.
>
> This kernel crash is hard to reproduce.
>
Can you test this patch.
Note, there's a similar bug on
On Sun, 12 Nov 2023 23:00:30 +0800
Kairui Song wrote:
> From: Kairui Song
>
> Following kernel panic was observed when doing ftrace stress test:
>
> Unable to handle kernel paging request at virtual address 9699b0f8ece28240
> Mem abort info:
> ESR = 0x9604
> EC = 0x25: DABT
On Sat, 11 Nov 2023 11:25:22 +0530
Krishna chaitanya chundru wrote:
> diff --git a/drivers/bus/mhi/host/trace.h b/drivers/bus/mhi/host/trace.h
> new file mode 100644
> index ..0e99318f5d08
> --- /dev/null
> +++ b/drivers/bus/mhi/host/trace.h
> +
>
On Fri, 10 Nov 2023 16:17:39 +0900
Masami Hiramatsu (Google) wrote:
> > + used = 0;
> > + hlist_for_each_entry_from_rcu(node, hlist) {
> > + if (node->addr != func)
> > + break;
> > + fp = READ_ONCE(node->fp);
> > + if (!fp ||
On Fri, 10 Nov 2023 10:51:54 +0900
Masami Hiramatsu (Google) wrote:
> So this patch registers ftrace_ops for each fgraph_ops to ftrace.
> This means that the ftrace_graph_func() will be called twice or more
> on the same function.
> Thus should I call ftrace_startup() once when the first
On Thu, 9 Nov 2023 09:51:18 -0800
Josh Poimboeuf wrote:
> > I guess I'm not fully understanding what the cond rescheds are for. But
> > would an IPI to all CPUs setting NEED_RESCHED, fix it?
>
> If all livepatch arches had the ORC unwinder, yes.
>
> The problem is that frame pointer (and
On Thu, 9 Nov 2023 09:26:37 -0800
Josh Poimboeuf wrote:
> On Tue, Nov 07, 2023 at 06:16:09PM -0500, Steven Rostedt wrote:
> > On Tue, 7 Nov 2023 13:56:53 -0800
> > Ankur Arora wrote:
> >
> > > This reverts commit e3ff7c609f39671d1aaff4fb4a8594e14f3e03f8.
&
On Tue, 7 Nov 2023 13:56:53 -0800
Ankur Arora wrote:
> This reverts commit e3ff7c609f39671d1aaff4fb4a8594e14f3e03f8.
>
> Note that removing this commit reintroduces "live patches failing to
> complete within a reasonable amount of time due to CPU-bound kthreads."
>
> Unfortunately this fix
On Tue, 7 Nov 2023 08:48:44 -0500
Steven Rostedt wrote:
> On Tue, 7 Nov 2023 14:43:28 +0900
> Masami Hiramatsu (Google) wrote:
>
> > >
> > > It's only needed if an architecture supports direct trampolines.
> >
> > I see, and x86_64 needs it.
>
On Tue, 7 Nov 2023 14:43:28 +0900
Masami Hiramatsu (Google) wrote:
> >
> > It's only needed if an architecture supports direct trampolines.
>
> I see, and x86_64 needs it.
> OK, maybe better to keep it clear on x86-64 even on the
> return handler.
As it is arch specific, I'm not sure it
On Tue, 7 Nov 2023 10:49:24 +0900
Masami Hiramatsu (Google) wrote:
> > I've changed this, because fprobe entry handler is not called via
> > fgraph without this. But maybe I have to set correct gops->ops.func
> > after init?
>
> I confirmed that this is right because it is introduced by
>
On Tue, 7 Nov 2023 09:42:58 +0900
Masami Hiramatsu (Google) wrote:
> Got it. So does ftrace_regs need a placeholder for direct trampoline?
> (Or, can we use a register to pass it?)
> I think we don't need to clear it for return_to_handler() but if
> `ftrace_regs` spec requires it, it is better
On Sat, 4 Nov 2023 01:05:34 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Fix to check the tracepoint event is not valid with $retval.
> The commit 08c9306fc2e3 ("tracing/fprobe-event: Assume fprobe is
> a return event by $retval") introduced automatic return
On Mon, 6 Nov 2023 10:05:49 +0900
Masami Hiramatsu (Google) wrote:
> So for x86-64,
>
> - rdi, rsi, rcx, rdx, r8, r9, and rsp
> - rax and rdx
> - rbp
>
> (BTW, why orig_rax is cleared?)
You mean from ftrace_caller?
That's a "hack" to determine if we need to call the direct trampoline or
On Sun, 5 Nov 2023 18:33:01 -0500
Steven Rostedt wrote:
> For x86_64, that would be:
>
> rdi, rsi, rdx, r8, r9, rsp
I missed rcx.
-- Steve
hat's not the case for arm64, as
arch_ftrace_get_regs() will always return NULL.
>
> > You even Acked the patch:
> >
> > commit 02a474ca266a47ea8f4d5a11f4ffa120f83730ad
> > Author: Steven Rostedt (VMware)
> > Date: Tue Oct 27 10:55:55 2020 -0400
>
>
On Sun, 5 Nov 2023 14:11:30 -0500
Steven Rostedt wrote:
> You even Acked the patch:
More specifically, you acked the series and stressed the ftrace_regs
wrapper part when doing so:
https://lore.kernel.org/all/20201113080733.gz2...@hirez.programming.kicks-ass.net/
> On Thu, Nov 12
egs) and if
this "wrapper" had all valid pt_regs registers, then it would return
the pt_regs, otherwise it would return NULL, and you would need to use
the ftrace_regs accessor calls to get the function registers. You and
Thomas agreed with this.
You even Acked the patch:
commit 02a474ca26
On Thu, 2 Nov 2023 12:05:33 +0530
Mukesh Ojha wrote:
> I will try to participate and take this in a good way..but i thought
> for easier change where there is no discussion is needed., it is fine
> to add if you have spent time in checking the code and change is proper.
If it's easy then
On Wed, 1 Nov 2023 22:32:54 -0400
Steven Rostedt wrote:
> > Ouch! I thought the file descriptor has been hold by the opened process.
>
> Well, the struct *filp is, but not the filp->private that points to the
> struct trace_event_file *file.
That was supposed to be
On Thu, 2 Nov 2023 11:14:33 +0900
Masami Hiramatsu (Google) wrote:
> >
> > What happens here is that the kprobe event creates a trace_event_file
> > "file" descriptor that represents the file in tracefs to the event. It
> > maintains state of the event (is it enabled for the given instance?).
>
On Thu, 2 Nov 2023 08:43:32 +0900
Masami Hiramatsu (Google) wrote:
> On Tue, 31 Oct 2023 18:33:30 -0400
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > Now that inodes and dentries are created on the fly, they are also
&g
On Mon, 30 Oct 2023 21:57:13 +0530
Mukesh Ojha wrote:
> On 10/30/2023 9:45 PM, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > The eventfs_remove_rec() had some missing parameters in the kerneldoc
> > comment above it. Also, rephrase the
701 - 800 of 34188 matches
Mail list logo
