On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Subject: [PATCH] eventfs: Don't return NULL in eventfs_create_dir()
>
> Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry") added another check, testing if the parent was freed after
> we released the
From: Steven Rostedt
The mapping of the ring buffer to memory allocated at boot up will also
expose a "last_boot_info" to help tooling to read the raw data from the
last boot. As instances that have their ring buffer mapped to fixed
memory cannot perform snapshots, they can e
On Fri, 19 Jul 2024 12:26:33 +0200
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This variable is used only in an #ifdef, which causes a W=1 warning
> with some compilers:
>
> kernel/trace/trace.c:7570:37: error: 'last_boot_fops' defined but not used
> [-Werror=unused-const-variable=]
>
On Thu, 18 Jul 2024 08:29:23 -0700
Andrii Nakryiko wrote:
> Ping. What's the status of this patch? Is it just waiting until after
> the merge window, or it got lost?
It's probably best to re-ping after rc1 is out. With recent events, a
lot of us are way behind in our work.
Thanks,
-- Steve
On Wed, 17 Jul 2024 09:27:58 -0700
Namhyung Kim wrote:
> Hello,
>
> On Fri, Jul 12, 2024 at 12:45 PM Guilherme Amadio wrote:
> >
> > Hi Namhyung, Arnaldo,
> >
> > Here is version 3 of the patchset. I see the change to send output to
> > devnull
> > has already been applied, so I am submitting
On Tue, 16 Jul 2024 22:19:05 +0300
Nikita Kiryushin wrote:
> On 7/16/24 12:45, Alexey Khoroshilov wrote:
> > Yes, but there is another possible modification: replacement of call to
> > nonseekable_open() by a call to some other function that returns error.
> > Current code is already ready for
On Mon, 15 Jul 2024 15:10:17 -0400
Mathieu Desnoyers wrote:
> On 2024-07-15 14:47, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Gone but never forgotten.
> >
> > [ Also moved Daniel's name to be consistent with the alphabetica
[ Adding sched maintainers, as this is a scheduling trace event ]
On Wed, 3 Jul 2024 11:33:53 +0800
Tio Zhang wrote:
> Switch the order of prev_comm and next_comm in sched_switch's code to
> align with its printing order.
I'm going to pick this up in my tree, as it is pretty much a nop. It's
On Fri, 28 Jun 2024 11:46:11 +0100
Vincent Donnefort wrote:
> This is based on the mm-unstable branch [1] as it depends on David's work [2]
> for allowing the zero-page in vm_insert_page().
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
> [2]
From: "Steven Rostedt (Google)"
Gone but never forgotten.
[ Also moved Daniel's name to be consistent with the alphabetical order ]
Signed-off-by: Steven Rostedt (Google)
---
CREDITS | 10 +++---
MAINTAINERS | 3 ---
2 files changed, 7 insertions(+), 6 deletions(-)
On Fri, 12 Jul 2024 23:12:58 +0300
Nikita Kiryushin wrote:
> There is a trace_array_put() in check result for
> nonseekable_open() in tracing_buffers_open(). However,
> it would be never executed as nonseekable_open never fails
> (by design).
>
> Remove the check and associated unreachable
On Thu, 11 Jul 2024 22:03:17 -0700
Christoph Hellwig wrote:
> On Thu, Jul 11, 2024 at 09:17:54PM -0400, Steven Rostedt wrote:
> > That "f->f_path.dentry" is a dereference of the passed in pointer. If we
> > did that in the TP_printk(), then it would dereference
On Thu, 11 Jul 2024 09:01:28 -0700
Christoph Hellwig wrote:
> On Wed, Jul 10, 2024 at 10:43:53PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > Since file_path() takes the output buffer as one of its arguments, we
> > might as well have it format directly into the tracepoint's
x and the exact errors or
> warnings encountered by each HT thread during the test.
>
> Reviewed-by: Ashok Raj
> Reviewed-by: Tony Luck
> Signed-off-by: Jithu Joseph
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
Reviewed-by: Steven Rostedt (Google)
-- Steve
>
On Thu, 4 Jul 2024 22:12:45 +0200
Jesper Dangaard Brouer wrote:
> >
> > WARNING: possible recursive locking detected
> > 6.10.0-rc2-syzkaller-00797-ga12978712d90 #0 Not tainted
> >
> > syz-executor646/5097
On Thu, 4 Jul 2024 13:03:47 +0200
Petr Pavlu wrote:
> > I'm dumb. What's an "era"?
>
> I meant it as a calendar era or epoch. The idea was to hint this is
> a number that identifies some structural state of the pages list. Maybe
> pages_gen ("generation") or another name would be better?
Ah,
at that point.
>
> Note that the symbol which has a unique name in the target module,
> it will be accepted even if there are same-name symbols in the
> kernel or other modules,
>
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Steven Rostedt (Google)
-- Steve
On Thu, 4 Jul 2024 22:56:29 +1000
Dave Chinner wrote:
> Having to do this is additional work when writing use-once scripts
> that get thrown away when the tracepoint output analysis is done
> is painful, and it's completely unnecessary if the tracepoint output
> is completely space separated
On Thu, 4 Jul 2024 11:15:59 +0200
Peter Zijlstra wrote:
> > Now, RCU Tasks Trace were specifically designed for least overhead
> > hotpath (reader side) performance, at the expense of slowing down much
> > rarer writers. My microbenchmarking does show at least 5% difference.
> > Both flavors can
On Wed, 3 Jul 2024 14:33:21 -0700
Namhyung Kim wrote:
> On Wed, Jul 03, 2024 at 03:36:17PM -0400, Steven Rostedt wrote:
> > On Tue, 2 Jul 2024 16:40:46 -0700
> > Namhyung Kim wrote:
> >
> > > +CC Steve and linux-trace-kernel list.
> >
>
On Wed, 3 Jul 2024 09:50:57 +0200
Peter Zijlstra wrote:
> > However, in the past, the memory-barrier and array-indexing overhead
> > of SRCU has made it a no-go for lightweight probes into fastpath code.
> > And these cases were what motivated RCU Tasks Trace (as opposed to RCU
> > Tasks Rude).
On Wed, 3 Jul 2024 09:53:14 +0200
Petr Pavlu wrote:
> The function rb_check_pages() validates the integrity of a specified
> per-CPU tracing ring buffer. It does so by traversing the underlying
> linked list and checking its next and prev links.
>
> To guarantee that the list isn't modified
On Tue, 2 Jul 2024 16:40:46 -0700
Namhyung Kim wrote:
> +CC Steve and linux-trace-kernel list.
There doesn't seem to be a cover page, and it doesn't apply on
v6.10-rc6 nor on tip.
-- Steve
On Wed, 3 Jul 2024 00:19:05 +0900
Masami Hiramatsu (Google) wrote:
> > BTW, is this (batched register/unregister APIs) something you'd like
> > to use from the tracefs-based (or whatever it's called, I mean non-BPF
> > ones) uprobes as well? Or there is just no way to even specify a batch
> > of
On Tue, 2 Jul 2024 11:32:53 -0400
Mathieu Desnoyers wrote:
> If we use '*' for user events already, perhaps we'd want to consider
> using the same range for the ring buffer ioctls ? Arguably one is
> about instrumentation and the other is about ring buffer interaction
> (data transport), but
On Tue, 2 Jul 2024 19:27:16 +0900
Takaya Saeki wrote:
> Hello all, and thank you so much for the review, Steven and Masami.
>
> I'm currently considering replacing the `max_ofs` output with
> `length`. Please let me know your thoughts.
> With the current design, a memory range of an event is an
On Tue, 2 Jul 2024 10:36:03 -0400
Mathieu Desnoyers wrote:
> > I can send a patch this week to update it. Or feel free to send a patch
> > yourself.
>
> You need to reserve an unused ioctl Code and Seq# range within:
>
> Documentation/userspace-api/ioctl/ioctl-number.rst
Ug, it's been so
On Wed, 12 Jun 2024 09:11:56 +0800
Hongbo Li wrote:
> @@ -934,6 +943,12 @@ static int hugetlbfs_setattr(struct mnt_idmap *idmap,
> if (error)
> return error;
>
> + trace_hugetlbfs_setattr(inode, dentry->d_name.len, dentry->d_name.name,
> +
On Sun, 30 Jun 2024 13:53:23 +0300
"Dmitry V. Levin" wrote:
> On Fri, May 10, 2024 at 03:04:32PM +0100, Vincent Donnefort wrote:
> [...]
> > diff --git a/include/uapi/linux/trace_mmap.h
> > b/include/uapi/linux/trace_mmap.h
> > index b682e9925539..bd1066754220 100644
> > ---
On Thu, 27 Jun 2024 19:40:44 -0500
Eric Sandeen wrote:
> Convert to new uid/gid option parsing helpers
>
> Signed-off-by: Eric Sandeen
Acked-by: Steven Rostedt (Google)
-- Steve
On Thu, 27 Jun 2024 02:35:16 +
Kuppuswamy Sathyanarayanan wrote:
> From: Jithu Joseph
>
> Add tracing support for the SBAF IFS tests, which may be useful for
> debugging systems that fail these tests. Log details like test content
> batch number, SBAF bundle ID, program index and the exact
On Wed, 26 Jun 2024 10:48:23 +0200
Alice Ryhl wrote:
> >
> > Because your hooks/rust_binder.h and events/rust_binder.h use the same
> > TRACE_SYSTEM name? Could you try something like:
> >
> > #define TRACE_SYSTEM rust_binder_hook
> >
> > in your hooks/rust_binder.h?
>
> I was able to
This looks good to me from the trace-event point of view.
>
> Reviewed-by: Masami Hiramatsu (Google)
I added my reviewed-by on the last patch, you could have added it on
this one as it didn't change as much. But anyway, here it is again:
Reviewed-by: Steven Rostedt (Google)
-- Steve
ENT(qdisc_reset,
> TP_ARGS(q),
>
> TP_STRUCT__entry(
> - __string( dev,qdisc_dev(q)->name )
> + __string(dev, qdisc_dev(q) ? qdisc_dev(q)->name : "noop_queue")
From a tracing point of view:
R
->etype = iter->etype;
> + ent->key = (struct static_key *) iter->static_key_addr;
Nit, should there be a space between the typecast and the "iter"?
> ent->priv = priv;
> INIT_LIST_HEAD(>list);
> list_add_tail(
On Thu, 20 Jun 2024 00:48:55 +0200
Vlastimil Babka wrote:
> +static int debugfs_prob_set(void *data, u64 val)
> +{
> + struct fault_attr *attr = data;
> +
> + mutex_lock(_mutex);
> +
> + if (attr->active) {
> + if (attr->probability != 0 && val == 0) {
> +
-u |wc -l
6
Note, ureadahead ignores duplicate pages.
If these new events really do only show what is used and not what is
just pulled in, and doesn't miss anything, I can see it bringing down
the number of pages needed to be saved dramatically.
Reviewed-by: Steven Rostedt (Google)
-- Steve
On Tue, 18 Jun 2024 13:47:49 +0200
Alexander Graf wrote:
> IMHO the big fat disclaimer should be in the argument name.
> "reserve_mem" to me sounds like it actually guarantees a reservation -
> which it doesn't. Can we name it more along the lines of "debug" (to
> indicate it's not for
On Tue, 18 Jun 2024 20:55:17 +0800
Zhengyejian wrote:
> > + start = memblock_phys_alloc(size, align);
> > + if (!start)
> > + return -ENOMEM;
> > +
> > + reserved_mem_add(start, size, name);
> > +
> > + return 0;
>
> Hi, steve, should here return 1 ? Other __setup functions
On Thu, 13 Jun 2024 10:32:24 +0300
Ilkka Naulapää wrote:
> ok, so if you don't have any idea where this bug is after those debug
> patches, I'll try to find some time to bisect it as a last resort.
> Stay tuned.
FYI,
I just debugged a strange crash that was caused by my config having
something
On Mon, 17 Jun 2024 23:01:12 +0200
Alexander Graf wrote:
> > This could be an added feature, but it is very architecture specific,
> > and would likely need architecture specific updates.
>
>
> It definitely would be an added feature, yes. But one that allows you to
> ensure persistence a
On Mon, 17 Jun 2024 09:07:29 +0200
Alexander Graf wrote:
> Hey Steve,
>
>
> I believe we're talking about 2 different things :). Let me rephrase a
> bit and make a concrete example.
>
> Imagine you have passed the "reserve_mem=12M:4096:trace" kernel command
> line option. The kernel now
On Fri, 14 Jun 2024 14:10:58 -0400
Kris Van Hees wrote:
> On Fri, Jun 14, 2024 at 01:46:51PM -0400, Steven Rostedt wrote:
> > On Fri, 14 Jun 2024 13:14:26 -0400
> > Kris Van Hees wrote:
> >
> > > Module objects compiled from C source can
On Fri, 14 Jun 2024 13:14:26 -0400
Kris Van Hees wrote:
> Module objects compiled from C source can be identified by the presence
> of -DKBUILD_MODFILE and -DKBUILD_MODNAME on their compile command lines.
> However, module objects from assembler source do not have this defines.
>
> Add
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
ange log of the first patch as well as added an entry
into kernel-parameters.txt about how reserve_mem is for soft reboots
and may not be reliable.
Steven Rostedt (Google) (2):
mm/memblock: Add "reserve_mem" to reserved named memory at boot up
pstore/ramoops: Add ramoo
On Thu, 13 Jun 2024 14:21:10 -0700
Andrew Morton wrote:
> On Thu, 13 Jun 2024 16:10:12 -0400 Steven Rostedt wrote:
>
> > > And... I'm a bit surprised that forward declarations are allowed in C.
> > > A billion years ago I used a C compiler which would use 1
On Thu, 13 Jun 2024 22:22:18 +0300
Alexey Dobriyan wrote:
> g++ doesn't like forward enum declarations:
>
> error: use of enum ‘E’ without previous declaration
> 64 | enum E;
But we don't care about g++. Do we?
I would make that a separate patch.
>
> Delete those which aren't
On Thu, 13 Jun 2024 13:04:20 -0700
Andrew Morton wrote:
> On Thu, 13 Jun 2024 15:34:02 -0400 Steven Rostedt wrote:
>
> > On Thu, 13 Jun 2024 22:22:18 +0300
> > Alexey Dobriyan wrote:
> >
> > > g++ doesn't like forward enum declarations:
> > &g
On Thu, 13 Jun 2024 15:19:50 -0300
"Guilherme G. Piccoli" wrote:
> > +
> > + reserver_mem=2M:4096:oops ramoops.mem_name=oops
> > +
>
> Likely this could be fixed on merge, to avoid another version, but...
>
> s/reserver_mem/reserve_mem
That 'r' is my nemesis! Almost every time I type
PL() for reserve_mem_find_by_name()
- Removed "built-in" from module description that was changed from v1.
Changes since v1:
https://lore.kernel.org/all/2024060320.801075...@goodmis.org/
- Updated the change log of the first patch as well as added an entry
into kernel-parameters.txt ab
On Thu, 13 Jun 2024 18:54:12 +0200
Alexander Graf wrote:
>
> Do you have a "real" pstore on these systems that you could store
> non-volatile variables in, such as persistent UEFI variables? If so, you
> could create an actually persistent mapping for your trace pstore even
> across kernel
a stale partially
> unpoisoned stack frame. Poisoning stack frames before returns [1]
> makes the issue appear on x86_64 as well.
>
> [1]
> https://github.com/iii-i/llvm-project/commits/msan-poison-allocas-before-returning-2024-06-12/
>
> Reviewed-by: Alexander Potapenko
> Si
From: "Steven Rostedt (Google)"
In order to allow for requesting a memory region that can be used for
things like pstore on multiple machines where the memory layout is not the
same, add a new option to the kernel command line called "reserve_mem".
The format is: reser
From: "Steven Rostedt (Google)"
Add a method to find a region specified by reserve_mem=nn:align:name for
ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it
finds
From: "Steven Rostedt (Google)"
In function_graph_enter() there's a loop that looks at fgraph_array[]
elements which are fgraph_ops. It first tests if it is a fgraph_stub op,
and if so skips it, as that's just there as a place holder. Then it checks
the fgraph_ops filters to see if the
On Thu, 13 Jun 2024 15:11:07 +0800
Andy Chiu wrote:
> kernel_text_address() and __kernel_text_address() are called in
> arch_stack_walk() of riscv. This results in excess amount of un-related
> traces when the kernel is compiled with CONFIG_TRACE_IRQFLAGS. The
> situation worsens when
From: "Steven Rostedt (Google)"
The addresses of a stack trace event are relative to the kallsyms. As that
can change between boots, when printing the stack trace from a buffer that
was from the last boot, it needs all the addresses to be added to the
"text_delta" that giv
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)"
Add an option to the trace_instance kernel command line parameter that
allows it to use the reserved memory from memmap boot parameter.
memmap=12M$0x28450 trace_instance=boot_mapped@0x28450:12M
The above will reserves 12 megs at the physic
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)"
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)"
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 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)"
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
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)"
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 evenly for the per CPU ring buffers.
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
fer code.
- Added hard coded address to map to (from memmap=nn$ss), instead of relying
on using reserve_mem (which I still want to add).
- Updated comments
- Restructured the validate code as the previous version broke the ring
buffer timestamp validation code.
Steven Rostedt (Google) (13):
On Wed, 12 Jun 2024 16:09:40 +0200
"Jason A. Donenfeld" wrote:
> >
> > I think "Depends-on" is the way to go, as it is *not* a stable thing, and
> > what is in stable rules is only about stable patches.
>
> How does "Depends-on" not spiral out of control? There's a *lot* of
> "Depends-on"
> also, let me know and I'll rerun it.
> >
> > --Ilkka
> >
> > On Thu, May 30, 2024 at 5:00 PM Steven Rostedt wrote:
> >
> >>
> >> On Thu, 30 May 2024 16:02:37 +0300
> >> Ilkka Naulapää wrote:
> >>
> >>>
On Tue, 11 Jun 2024 22:16:43 -0400
Steven Rostedt wrote:
> 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
From: "Steven Rostedt (Google)"
The addresses of a stack trace event are relative to the kallsyms. As that
can change between boots, when printing the stack trace from a buffer that
was from the last boot, it needs all the addresses to be added to the
"text_delta" that giv
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)"
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)"
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)"
Add an option to the trace_instance kernel command line parameter that
allows it to use the reserved memory from memmap boot parameter.
memmap=12M$0x28450 trace_instance=boot_mapped@0x28450:12M
The above will reserves 12 megs at the physic
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
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
o map to (from memmap=nn$ss), instead of relying
on using reserve_mem (which I still want to add).
- Updated comments
- Restructured the validate code as the previous version broke the ring
buffer timestamp validation code.
Steven Rostedt (Google) (13):
ring-buffer: Allow mapped field
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 evenly for the per CPU ring buffers.
On Tue, 11 Jun 2024 21:39:37 -0400
Steven Rostedt wrote:
> >
> > Maybe explain why sometimes __rb_inc_dec_mapped() is called to
> > increment or decrement ->mapped, and sometimes it id done directly ?
> > I can see that the function also acquires the buffer mu
On Tue, 11 Jun 2024 16:53:43 -0700
Guenter Roeck wrote:
> >>> @@ -6403,7 +6407,8 @@ int ring_buffer_unmap(struct trace_buffer *buffer,
> >>> int cpu)
> >>> mutex_lock(>mutex);
> >>> raw_spin_lock_irqsave(_buffer->reader_lock, flags);
> >>>
> >>> - cpu_buffer->mapped = 0;
ful, the generated events are cleaned up.
> And if not, we cannot guarantee that the kprobe events will work
> correctly. So, anyway, there is no need to clean it up.
>
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Steven Rostedt (Google)
-- Steve
On Tue, 11 Jun 2024 15:43:59 -0700
Guenter Roeck wrote:
> On 6/11/24 12:28, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > In preparation for having the ring buffer mapped to a dedicated location,
> > which will have the same restriction
From: "Steven Rostedt (Google)"
The addresses of a stack trace event are relative to the kallsyms. As that
can change between boots, when printing the stack trace from a buffer that
was from the last boot, it needs all the addresses to be added to the
"text_delta" that giv
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)"
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)"
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)"
Add an option to the trace_instance kernel command line parameter that
allows it to use the reserved memory from memmap boot parameter.
memmap=12M$0x28450 trace_instance=boot_mapped@0x28450:12M
The above will reserves 12 megs at the physic
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
1 - 100 of 34441 matches
Mail list logo
