...@google.com
Acked-by: Shuah Khan
Signed-off-by: Vincent Donnefort
Signed-off-by: Steven Rostedt (Google)
---
tools/testing/selftests/ring-buffer/map_test.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/testing/selftests/ring-buffer/map_test.c
b/tools/testing/selftests
: Shuah Khan
Signed-off-by: Vincent Donnefort
Signed-off-by: Steven Rostedt (Google)
---
tools/testing/selftests/ring-buffer/map_test.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/ring-buffer/map_test.c
b/tools/testing/selftests/ring-buffer
On Sat, 7 Sep 2024 15:15:06 +0800
Hui Guo wrote:
> Hi Kernel Maintainers,
> we found a crash "general protection fault in lookup_object_or_alloc"
> in upstream, and reproduced it successfully, this bug is a KASAN.
>
> HEAD Commit: 88fac17500f4ea49c7bac136cf1b27e7b9980075(Merge tag
> 'fuse-fixes-
On Tue, 27 Aug 2024 09:29:55 +0800
Zheng Yejian wrote:
> > This is the wrong place to put this. If the problem is with
> > tracing_iter_reset(), then add it there.
> >
> > while (ring_buffer_iter_peek(buf_iter, &ts)) {
> > if (ts >= iter->array_buffer->time_start)
> >
On Mon, 26 Aug 2024 15:01:24 +0200
Tomas Glozar wrote:
> > Before the reset, all but one of the tlat->kthread is NULL. Then it dawned
> > on me that this is a global per CPU variable. It gets initialized when the
> > tracer starts. If another program is has the timerlat fd open when the
> > trace
On Sat, 24 Aug 2024 11:03:43 +0800
Zheng Yejian wrote:
> In __tracing_open(), when max latency tracers took place on the cpu,
> the time start of its buffer would be updated, then event entries with
> timestamps being earlier than start of the buffer would be skipped
> (see tracing_iter_reset()).
On Fri, 23 Aug 2024 12:54:26 -0400
Steven Rostedt wrote:
> > $ while true; do rtla timerlat top -u -q & PID=$!; sleep 5; \
> > kill -INT $PID; sleep 0.001; kill -TERM $PID; wait $PID; done
>
> The "kill -INT $PID" caused the write to osnoise_workload_start()
On Tue, 20 Aug 2024 15:00:01 +0200
tglo...@redhat.com wrote:
> From: Tomas Glozar
>
> When running timerlat with a userspace workload (NO_OSNOISE_WORKLOAD),
> NULL pointer dereference can be triggered by sending consequent SIGINT
> and SIGTERM signals to the workload process. That then causes
>
From: Steven Rostedt
The start_kthread() and stop_thread() code was not always called with the
interface_lock held. This means that the kthread variable could be
unexpectedly changed causing the kthread_stop() to be called on it when it
should not have been, leading to:
while true; do
rtla
On Thu, 22 Aug 2024 08:20:52 -0300
"Luis Claudio R. Goncalves" wrote:
> You mean the
>
> + if (!tlat_var->kthread) {
> + /* the fd has been closed already */
>
> bit or the kthread handling in rtla itself?
>
> As Tomas already said, thank you for testing and reviewing the sugg
On Thu, 22 Aug 2024 10:32:02 -0400
Steven Rostedt wrote:
> > Yeah, it seems there might be multiple bugs in the user workload
> > handling, the other NULL pointer dereference and refcount warning
> > above might be related (but I have yet to reproduce it on an upstream
>
On Thu, 22 Aug 2024 11:32:07 +0200
Tomas Glozar wrote:
> st 21. 8. 2024 v 22:02 odesílatel Steven Rostedt napsal:
> >
> > I'm able to reproduce this with the above. Unfortunately, I can still
> > reproduce it after applying this patch :-(
> >
>
> Thank y
On Tue, 20 Aug 2024 15:00:01 +0200
tglo...@redhat.com wrote:
> From: Tomas Glozar
>
> When running timerlat with a userspace workload (NO_OSNOISE_WORKLOAD),
> NULL pointer dereference can be triggered by sending consequent SIGINT
> and SIGTERM signals to the workload process. That then causes
>
From: Steven Rostedt
When printing a dynamic array in a trace event, the method is rather ugly.
It has the format of:
__print_array(__get_dynamic_array(array),
__get_dynmaic_array_len(array) / el_size, el_size)
Since dynamic arrays are known to the tracing infrastructure, create
On Thu, 15 Aug 2024 16:16:33 -0500
Avadhut Naik wrote:
> diff --git a/include/trace/events/mce.h b/include/trace/events/mce.h
> index 65aba1afcd07..1e7d5696b3ba 100644
> --- a/include/trace/events/mce.h
> +++ b/include/trace/events/mce.h
> @@ -43,6 +43,8 @@ TRACE_EVENT(mce_record,
>
On Fri, 28 Jun 2024 11:46:11 +0100
Vincent Donnefort wrote:
> diff --git a/tools/testing/selftests/ring-buffer/map_test.c
> b/tools/testing/selftests/ring-buffer/map_test.c
> index a9006fa7097e..4bb0192e43f3 100644
> --- a/tools/testing/selftests/ring-buffer/map_test.c
> +++ b/tools/testing/self
On Wed, 21 Aug 2024 16:42:07 +0100
Mark Rutland wrote:
> FWIW, that was in samples/ftrace/ftrace-ops.c, where tracee_relevant() and
> tracee_irrelevant() have the barrier():
>
> | /*
> | * Marked as noinline to ensure that an out-of-line traceable copy is
> | * generated by the compiler.
> |
On Wed, 21 Aug 2024 21:27:55 +0800
Jeff Xie wrote:
Hi Jeff,
Thanks for the patch.
> Signed-off-by: Jeff Xie
> ---
> kernel/trace/trace_functions.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> in
On Wed, 21 Aug 2024 08:43:51 +0900
Masami Hiramatsu (Google) wrote:
> > Can you add the __used and see if it fixes it?
>
> Adding __used to DYN_FTRACE_TEST_NAME() and DYN_FTRACE_TEST_NAME2() does
> not change, the test still fails.
OK, now that sounds like a bug in LTO itself.
-- Steve
On Wed, 21 Aug 2024 07:05:39 +0900
Masami Hiramatsu (Google) wrote:
> Does the noinline attribute prevent embedding callsite too? I mean
>
> extern callee()
>
> noinline callee()
> {
> ...
> }
>
> caller()
> {
> callee() // (*)
> }
>
> In this case, does noinline prevent LTO to embed t
On Tue, 20 Aug 2024 08:10:42 -0700
Sami Tolvanen wrote:
> On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
> > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > > On Mon, 19 Aug 2024 12:02:44 -0400
> > > Steven Rostedt wrote:
>
On Tue, 20 Aug 2024 11:48:07 +0100
Mark Rutland wrote:
> > I found the target function already has "noinline". I tried to add noinline
> > to the testing function (callsite), but it also did not work.
> > I think "noinline" is for the compiler, but LTO is done by the linker.
>
> If LTO is brea
On Thu, 27 Jun 2024 11:23:35 -0400
Mathieu Desnoyers wrote:
> To cover scenarios where the scope of the guard differs from the scope
> of its activation, introduce DEFINE_INACTIVE_GUARD() and activate_guard().
>
> Here is an example use for a conditionally activated guard variable:
>
> void fun
Hi Johannes,
I finally got around to testing your patches.
I did the following:
# cat /sys/kernel/tracing/events/*/*/format
and hit this:
BUG: unable to handle page fault for address: 8e6333d0
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD
On Tue, 20 Aug 2024 00:56:49 +0900
Masami Hiramatsu (Google) wrote:
>
> >
> > We may need to add "noinline" or something to make sure those functions
> > don't get inlined for LTO.
>
> Yeah, we need such option at least for function call test.
Could you add the noinline, and if it fixes the
On Mon, 19 Aug 2024 17:11:52 +0900
Masami Hiramatsu (Google) wrote:
> CONFIG_LTO=y
> CONFIG_LTO_CLANG=y
Hi Masami,
Does it still fail if you disable the above?
I wonder if that causes functions to not be part of the available filter
functions that the ftrace filter test is using :-/
We may ne
From: Steven Rostedt
Add a magic number as well as save the struct size of the ring_buffer_meta
structure in the meta data to also use as validation. Updating the magic
number could be used to force a invalidation between kernel versions, and
saving the structure size is also a good method to
From: Steven Rostedt
The text and data address is saved in the meta data so that it can be used
to know the delta of the text and data addresses of the last boot compared
to the text and data addresses of the current boot. The delta is used to
convert function pointer entries in the ring buffer
From: "Steven Rostedt (Google)"
Allow boot instances to use memory reserved by the reserve_mem boot
option.
reserve_mem=12M:4096:trace trace_instance=boot_mapped@trace
The above will allocate 12 megs with 4096 alignment and label it "trace".
The second parameter will c
Hmm, does this handle my concern from the last patch. That is, if the
previous script is broken by some change, this will catch it?
If so, should there be a way to run this always? As it looks to be only
used for manual tests.
On Mon, 15 Jul 2024 23:10:44 -0400
Kris Van Hees wrote:
> The modul
--whole-archive vmlinux.a --no-whole-archive \
> --start-group $(KBUILD_VMLINUX_LIBS) --end-group \
> diff --git a/scripts/generate_builtin_ranges.awk
> b/scripts/generate_builtin_ranges.awk
> new file mode 100755
> index ..9b647781d5fe
> --- /dev/null
>
files.
The rest looks good.
Reviewed-by: Steven Rostedt (Google)
-- Steve
>
> Signed-off-by: Kris Van Hees
> ---
> scripts/Makefile.lib | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 9f06
On Mon, 15 Jul 2024 23:10:41 -0400
Kris Van Hees wrote:
> Especially for tracing applications, it is convenient to be able to
> refer to a symbol using a pair and to be able
> to translate an address into a pair. But
> that does not work if the module is built into the kernel because the
> obj
From: Steven Rostedt
Update the function graph code to modify the function addresses for a
previous boot buffer so that it matches the current kallsyms (note this
does not handle module addresses, yet).
After a reboot, instead of seeing:
# trace-cmd show -B boot_mapped | tail -n30
From: "Steven Rostedt (Google)"
Allow boot instances to use memory reserved by the reserve_mem boot
option.
reserve_mem=12M:4096:trace trace_instance=boot_mapped@trace
The above will allocate 12 megs with 4096 alignment and label it "trace".
The second parameter will c
n linux-next, I do not want to
rebase it, so instead I merged in v6.11-rc1 to get access to the
reserve_mem kernel command line parameter and applied these patches on top.
Steven Rostedt (1):
tracing/fgraph: Have fgraph handle previous boot function addresses
Steven Rostedt (Google) (1):
On Fri, 9 Aug 2024 13:53:33 -0400 (EDT)
John Kacur wrote:
> > > Although your fix appears to be correct, I wonder if it would be better
> > > to
> > > create a second error label, such as out_destroy_tool: as described in
> > > section 7 of the coding-style.rst
> > >
> >
> > There's no re
On Fri, 9 Aug 2024 13:34:28 -0400 (EDT)
John Kacur wrote:
> On Fri, 9 Aug 2024, Dan Carpenter wrote:
>
> > If the "tool->data" allocation fails then there is no need to call
> > osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.
> >
> > Fixes: 1eceb2fc2ca5 ("rtla/osnoise
From: Steven Rostedt
When running the following:
# cd /sys/kernel/tracing/
# echo 1 > events/sched/sched_waking/enable
# echo 1 > events/sched/sched_switch/enable
# echo 0 > tracing_on
# dd if=per_cpu/cpu0/trace_pipe_raw of=/tmp/raw0.dat
The dd task would get stuck in an infinit
On Thu, 20 Jun 2024 16:19:03 +
Takaya Saeki wrote:
> +DECLARE_EVENT_CLASS(mm_filemap_op_page_cache_range,
> +
> + TP_PROTO(
> + struct address_space *mapping,
> + pgoff_t index,
> + pgoff_t last_index
> + ),
> +
> + TP_ARGS(mapping, index, last_
From: Steven Rostedt
With structure layout randomization enabled for 'struct inode' we need to
avoid overlapping any of the RCU-used / initialized-only-once members,
e.g. i_lru or i_sb_list to not corrupt related list traversals when making
use of the rcu_head.
For an unlucky struct
On Tue, 11 Jun 2024 16:49:24 +0200
Alejandro Colomar wrote:
> Hi,
>
> On Tue, Jun 11, 2024 at 11:30:22PM GMT, Masami Hiramatsu wrote:
> > On Tue, 11 Jun 2024 13:21:58 +0200
> > Jiri Olsa wrote:
> >
> > > Adding man page for new uretprobe syscall.
> > >
> > > Acked-by: Andrii Nakryiko
> > >
On Wed, 7 Aug 2024 19:41:11 +
Song Liu wrote:
> It appears there are multiple APIs that may need change. For example, on gcc
> built kernel, /sys/kernel/tracing/available_filter_functions does not show
> the suffix:
>
> [root@(none)]# grep cmos_irq_enable /proc/kallsyms
> 81db
On Wed, 7 Aug 2024 14:44:53 +0100
Al Viro wrote:
> On Wed, Aug 07, 2024 at 09:35:45AM -0400, Steven Rostedt wrote:
>
> > Perhaps:
> >
> > diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
> > index f704d8348357..ab6d6c3d835d 100644
> > --- a/fs/tra
On Wed, 7 Aug 2024 13:51:39 +0200
Mathias Krause wrote:
> diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
> index f704d8348357..a7769857962a 100644
> --- a/fs/tracefs/internal.h
> +++ b/fs/tracefs/internal.h
> @@ -10,10 +10,8 @@ enum {
> };
>
> struct tracefs_inode {
> - union
On Wed, 7 Aug 2024 13:51:37 +0200
Mathias Krause wrote:
> Hi Steven,
>
> We ran into yet another tracefs related bug but, fortunately, were able
> to root cause it ourselves.
>
> The problem only occurs when CONFIG_RANDSTRUCT is enabled and one gets
> (un)lucky to hit a random seed that'll ove
On Wed, 7 Aug 2024 11:34:43 +
Tze-nan Wu (吳澤南) wrote:
> > > -idx = atomic_inc_return(&map->next_elt);
> > > +idx = atomic_fetch_add_unless(&map->next_elt, 1, map->max_elts);
> >
> > I guess we need to add (with a comment):
> >
> > idx--;
> >
> Thanks for reviewing this!
>
> By referen
On Tue, 6 Aug 2024 16:00:49 -0400
Steven Rostedt wrote:
> > >> + if (IS_ENABLED(CONFIG_LTO_CLANG) && !addr)
> > >> + addr = kallsyms_lookup_name_without_suffix(trace_kprobe_symbol(tk));
> > >> +
> > >
> > > So you do the
On Tue, 6 Aug 2024 19:35:07 +
Song Liu wrote:
> >> + if (IS_ENABLED(CONFIG_LTO_CLANG) && !addr)
> >> + addr = kallsyms_lookup_name_without_suffix(trace_kprobe_symbol(tk));
> >> +
> >
> > So you do the lookup twice if this is enabled?
> >
> > Why not just use "kallsyms_lookup_name_without_
On Mon, 5 Aug 2024 13:59:22 +0800
Tze-nan Wu wrote:
> "tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
>
> Once it overflows, new elements can still be inserted into the tracing_map
> even though the maximum number of elements (`max_elts`) has been reached.
> Continuing to in
On Fri, 2 Aug 2024 14:08:35 -0700
Song Liu wrote:
> Use the new kallsyms APIs that matches symbols name with .XXX
> suffix. This allows userspace tools to get kprobes on the expected
> function name, while the actual symbol has a .llvm. suffix.
>
> This only effects kernel compile with CONFIG_L
On Tue, 30 Jul 2024 11:35:27 +0100
Gary Guo wrote:
> > +/*
> > + * Declare an exported function that Rust code can call to trigger this
> > + * tracepoint. This function does not include the static branch; that is
> > done
> > + * in Rust to avoid a function call when the tracepoint is disabled.
On Wed, 31 Jul 2024 10:36:53 +0200
tglo...@redhat.com wrote:
> From: Tomas Glozar
>
> Add option to limit deepest idle state on CPUs where timerlat is running
> for the duration of the workload.
>
> Signed-off-by: Tomas Glozar
> ---
> tools/tracing/rtla/src/timerlat_top.c | 46 +++
On Wed, 31 Jul 2024 10:36:52 +0200
tglo...@redhat.com wrote:
> From: Tomas Glozar
>
> Add functions to utils.c to disable idle states through functions of
> libcpupower. This will serve as the basis for disabling idle states
> per cpu when running timerlat.
>
> Signed-off-by: Tomas Glozar
> --
On Tue, 30 Jul 2024 11:06:57 -0400
Steven Rostedt wrote:
> Link:
> https://lore.kernel.org/all/20240719204701.1605950-1-mini...@grsecurity.net/
>
> Cc: sta...@vger.kernel.org
> Fixes: b63db58e2fa5d ("eventfs/tracing: Add callback for release of an
> eventfs_inode&q
From: Steven Rostedt
When eventfs was introduced, special care had to be done to coordinate the
freeing of the file meta data with the files that are exposed to user
space. The file meta data would have a ref count that is set when the file
is created and would be decremented and freed after the
On Tue, 30 Jul 2024 09:22:53 +0200
Uwe Kleine-König wrote:
> I think the patch is obvious enough to be ok even without the tracing
> maintainer's blessing. I applied it to
> https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git
> pwm/for-next
> .
No problem. Thanks for the Cc. I do
On Mon, 29 Jul 2024 23:49:24 +0900
Masami Hiramatsu (Google) wrote:
> On Fri, 26 Jul 2024 14:42:08 -0400
> Steven Rostedt wrote:
>
> > From: Steven Rostedt
> >
> > Instead of using an atomic counter for the trace_event_file reference
> > counter, use the r
On Mon, 29 Jul 2024 18:29:49 +0530
Ajay Kaher wrote:
> Following is not related to this bug:
> event_release callback executed once 'dir' closed (no more ref), any
> specific reason to register with 'dir'/'enable' file. If not, could we
> register with the 'dir' instead of 'enable'.
I tried that
On Fri, 26 Jul 2024 21:58:30 +0200
Mathias Krause wrote:
> >>
> >> IMHO, this needs at least the following additional fixes tags to ensure
> >> all stable kernels get covered:
> >>
> >> Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use
> >> eventfs_inode")
> >> Fixes: 27152bceea1d ("
From: Steven Rostedt
Instead of using an atomic counter for the trace_event_file reference
counter, use the refcount interface. It has various checks to make sure
the reference counting is correct, and will warn if it detects an error
(like refcount_inc() on '0').
Signed-off-by: Stev
From: Steven Rostedt
When eventfs was introduced, special care had to be done to coordinate the
freeing of the file meta data with the files that are exposed to user
space. The file meta data would have a ref count that is set when the file
is created and would be decremented and freed after the
On Fri, 26 Jul 2024 18:00:18 +0530
Ajay Kaher wrote:
> Some doubt:
> Because of the same race condition, it may happen that kmem_cache_free(file)
> was executed while f_start() is waiting to get event_mutex. Once
> f_start() acquires
> event_mutex, it will access the *file which points to the fre
t;eventfs: Move tracing/events to eventfs")
>
> Even if 27152bceea1d is not the real cause, just the commit making the
> bug reachable. But from looking at the history, this was always wrong?
All stable kernels should get covered as 27152bceea1d has both a Cc
stable tag and a Fixes t
From: Steven Rostedt
When eventfs was introduced, special care had to be done to coordinate the
freeing of the file meta data with the files that are exposed to user
space. The file meta data would have a ref count that is set when the file
is created and would be decremented and freed after the
On Thu, 25 Jul 2024 23:32:30 +0200
Mathias Krause wrote:
> That was for a single run of
> tools/testing/selftests/user_events/ftrace_test with the read loop of
> /sys/kernel/tracing/events/user_events/__test_event/format in a
> different shell.
>
> >
> > destroy_user_event() which is under even
On Thu, 25 Jul 2024 22:41:23 +0200
Mathias Krause wrote:
> > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> > index 6ef29eba90ce..5fbfa1c885de 100644
> > --- a/kernel/trace/trace_events.c
> > +++ b/kernel/trace/trace_events.c
> > @@ -1627,12 +1627,14 @@ static int f_show
On Thu, 25 Jul 2024 21:42:41 +0200
Mathias Krause wrote:
> Right. But the point is, that 'event_call' is really some '&user->call'.
> With 'user' being free'd memory, what gives? Dereferencing 'event_call'
> is UB, so this function is doomed to fail because it cannot know if its
> only argument p
On Thu, 25 Jul 2024 20:12:33 +0200
Mathias Krause wrote:
>
> >
> >> +
> >>if (WARN_ON_ONCE(!schedule_work(&user->put_work))) {
> >>/*
> >> * If we fail we must wait for an admin to attempt delete or
> >> @@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t b
On Thu, 25 Jul 2024 13:10:21 -0400
Steven Rostedt wrote:
>
> diff --git a/kernel/trace/trace_events_user.c
> b/kernel/trace/trace_events_user.c
> index 3a2b46847c8b..e9ed2826ff46 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
On Thu, 25 Jul 2024 22:00:14 +0530
Ajay Kaher wrote:
> Thread A (read event) Thread B (remove event)
>
> . worker_thread()
> . delayed_destroy_user_event()
> .
On Thu, 25 Jul 2024 21:45:03 +0530
Ajay Kaher wrote:
> On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
> >
> > On 22.07.24 13:13, Ajay Kaher wrote:
> > > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > > wrote:
> > >>
> > >> I noticed, the user events ftrace selftest is crashing e
On Tue, 23 Jul 2024 23:07:53 +0200
Mathias Krause wrote:
> To mirror the SRCU lock held in eventfs_iterate() when iterating over
> eventfs inodes, use call_srcu() to free them too.
>
> This was accidentally(?) degraded to RCU in commit 43aa6f97c2d0
> ("eventfs: Get rid of dentry pointers without
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Beside the obvious bug, I noticed the following (not fixing the issue,
> tho):
>
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 5d88c184f0fc..687ad0a26458 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tra
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 mutex
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 eithe
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=]
> 757
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 su
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 alphabeti
[ 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] https://lore.kernel.org/all/2024
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 code.
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 i
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 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.
> >
> > The
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 dur
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 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 thos
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 lon
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
> > --- a/include/uapi/linux
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
t;
> 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
1 - 100 of 7784 matches
Mail list logo
