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
On Wed, 1 Nov 2023 18:32:14 +0100
Jiri Olsa wrote:
> hi,
> I'm doing some testing on top of fprobes and noticed that the
> ftrace_test_recursion_trylock allows caller from the same context
> going through twice.
>
> The change below adds extra fprobe on stack_trace_print, which is
> called
From: "Steven Rostedt (Google)"
Looking at how dentry is removed via the tracefs system, I found that
eventfs does not do everything that it did under tracefs. The tracefs
removal of a dentry calls simple_recursive_removal() that does a lot more
than a simple d_invalidate().
As
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, any changes to the ownership and mode
will be lost.
To counter this, if the us
From: "Steven Rostedt (Google)"
The callback function that is used to create inodes and dentries is not
protected by anything and the data that is passed to it could become
stale. After eventfs_remove_dir() is called by the tracing system, it is
free to remove the events that are
From: "Steven Rostedt (Google)"
There exists a race between holding a reference of an eventfs_inode dentry
and the freeing of the eventfs_inode. If user space has a dentry held long
enough, it may still be able to access the dentry's eventfs_inode after it
has been freed.
To prevent
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set unde
From: "Steven Rostedt (Google)"
As the eventfs_inode is freed in two different locations, make a helper
function free_ei() to make sure all the allocated fields of the
eventfs_inode is freed.
This requires renaming the existing free_ei() which is called by the srcu
handler to f
From: "Steven Rostedt (Google)"
The eventfs_inode->is_freed was a union with the rcu_head with the
assumption that when it was on the srcu list the head would contain a
pointer which would make "is_freed" true. But that was a wrong assumption
as the rcu head is a single l
From: "Steven Rostedt (Google)"
The top level events directory is no longer special with regards to how it
should be delete. Remove the extra processing for it in
eventfs_set_ei_status_free().
Cc: Ajay Kaher
Signed-off-by: Steven Rostedt (Google)
---
Changes since v5: https://lkml.
that
patch to after this series and to handle this rebase, I'm reposting
all the patches and including the above mentioned patch at the end
and renamed to:
eventfs: Use simple_recursive_removal() to clean up dentries
I hope this is the last series, as this *is* for this merge window!
Steven
On Wed, 1 Nov 2023 00:16:59 -0400
Steven Rostedt wrote:
> On Wed, 1 Nov 2023 02:25:53 +
> Al Viro wrote:
>
> > Umm... Is there any reason not to use simple_recursive_removal() there?
>
> Hmm, I may be able to (I'm still a newbie with understanding of the vfs).
&
On Wed, 1 Nov 2023 02:25:53 +
Al Viro wrote:
> On Tue, Oct 31, 2023 at 02:47:03PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Looking at how dentry is removed via the tracefs system, I found that
> > eventfs does not do
From: "Steven Rostedt (Google)"
There exists a race between holding a reference of an eventfs_inode dentry
and the freeing of the eventfs_inode. If user space has a dentry held long
enough, it may still be able to access the dentry's eventfs_inode after it
has been freed.
To prevent
From: "Steven Rostedt (Google)"
The top level events directory is no longer special with regards to how it
should be delete. Remove the extra processing for it in
eventfs_set_ei_status_free().
Signed-off-by: Steven Rostedt (Google)
---
fs/tracefs/event_inode.c | 19 ++---
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set unde
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, any changes to the ownership and mode
will be lost.
To counter this, if the us
From: "Steven Rostedt (Google)"
The callback function that is used to create inodes and dentries is not
protected by anything and the data that is passed to it could become
stale. After eventfs_remove_dir() is called by the tracing system, it is
free to remove the events that are
node after the last
dentry has cleared its reference (there's more races there without
doing that)
- Make the top level eventfs directory the same as the rest in
being removed.
Steven Rostedt (Google) (7):
eventfs: Remove "is_freed" union with rcu head
eventfs: Have a free_
From: "Steven Rostedt (Google)"
As the eventfs_inode is freed in two different locations, make a helper
function free_ei() to make sure all the allocated fields of the
eventfs_inode is freed.
This requires renaming the existing free_ei() which is called by the srcu
handler to f
From: "Steven Rostedt (Google)"
The eventfs_inode->is_freed was a union with the rcu_head with the
assumption that when it was on the srcu list the head would contain a
pointer which would make "is_freed" true. But that was a wrong assumption
as the rcu head is a single l
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set unde
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, any changes to the ownership and mode
will be lost.
To counter this, if the us
From: "Steven Rostedt (Google)"
As the eventfs_inode is freed in two different locations, make a helper
function free_ei() to make sure all the allocated fields of the
eventfs_inode is freed.
This requires renaming the existing free_ei() which is called by the srcu
handler to f
/2023103325.50087...@gandalf.local.home/
and
https://lore.kernel.org/linux-trace-kernel/20231031113627.2edfa...@gandalf.local.home/
With the stripped out free_ei() patch.
Steven Rostedt (Google) (3):
eventfs: Have a free_ei() that just frees the eventfs_inode
eventfs: Test for ei->is_fr
From: "Steven Rostedt (Google)"
A synthetic event is created by the synthetic event interface that can
read both user or kernel address memory. In reality, it reads any
arbitrary memory location from within the kernel. If the address space is
in U
From: "Steven Rostedt (Google)"
Looking at how dentry is removed via the tracefs system, I found that
eventfs does not do everything that it did under tracefs. The tracefs
removal of a dentry calls simple_recursive_removal() that does a lot more
than a simple d_invalidate().
Have the
From: "Steven Rostedt (Google)"
The creation of the top events directory does a dget() at the end of the
creation in eventfs_create_events_dir() with a comment saying the final
dput() will happen when it is removed. The problem is that a dget() is
already done on the dentry when it w
From: "Steven Rostedt (Google)"
The following can crash the kernel:
# cd /sys/kernel/tracing
# echo 'p:sched schedule' > kprobe_events
# exec 5>>events/kprobes/sched/enable
# > kprobe_events
# exec 5>&-
The above commands:
1. Change directory to the tracefs
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, any changes to the ownership and mode
will be lost.
To counter this, if the us
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set unde
From: "Steven Rostedt (Google)"
The eventfs_remove_rec() had some missing parameters in the kerneldoc
comment above it. Also, rephrase the description a bit more to have a bit
more correct grammar.
Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use
eventfs_in
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, any changes to the ownership and mode
will be lost.
To counter this, if the us
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The callback function that is used to create inodes and dentries is not
> protected by anything and the data that is passed to it could become
> stale. After eventfs_remove_dir() is called by the tracing syste
From: "Steven Rostedt (Google)"
The callback function that is used to create inodes and dentries is not
protected by anything and the data that is passed to it could become
stale. After eventfs_remove_dir() is called by the tracing system, it is
free to remove the events that are
On Mon, 30 Oct 2023 12:37:08 +0530
Naresh Kamboju wrote:
>
> I have tested the linux-trace.git trace/core and run selftests ftrace
> the reported kernel panic [1] & [2] has been fixed but found
Good to know. Can I add "Tested-by" from you for that bug fix?
> "general protection fault" at
On Sun, 29 Oct 2023 12:10:46 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> 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
From ae395d53794e7057c9a756e26865549a6b1a0840 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, a
On Sun, 29 Oct 2023 12:31:54 +0530
Naresh Kamboju wrote:
> Following build errors have been noticed.
>
> fs/tracefs/event_inode.c:348:1: error: return type defaults to 'int'
> [-Werror=implicit-int]
> 348 | create_dir_dentry(struct eventfs_inode *pei, struct eventfs_inode *ei,
> |
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set unde
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set unde
From: "Steven Rostedt (Google)"
It's eventfs_inode not eventfs_indoe. There's no deer involved!
Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode")
Signed-off-by: Steven Rostedt (Google)
---
fs/tracefs/internal.h | 2 +-
1 file changed, 1 inse
From: "Steven Rostedt (Google)"
As the comment right above a WARN_ON() in create_file_dentry() states:
* Note, with the mutex held, the e_dentry cannot have content
* and the ei->is_freed be true at the same time.
But the WARN_ON() only has:
WARN_ON_ONCE(ei->is_free);
On Mon, 23 Oct 2023 19:24:52 +0800
"wuqiang.matt" wrote:
> The objpool_push can only happen on local cpu node, so only the local
> cpu can touch slot->tail and slot->last, which ensures the correctness
> of using cmpxchg without lock prefix (using try_cmpxchg_local instead
> of
On Fri, 20 Oct 2023 09:03:59 -0600
Jeffrey Hugo wrote:
> > diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
> > index f78aefd2d7a3..3afa90a204fd 100644
> > --- a/drivers/bus/mhi/host/init.c
> > +++ b/drivers/bus/mhi/host/init.c
> > @@ -20,6 +20,9 @@
> > #include
> >
From: "Steven Rostedt (Google)"
The failure path of allocating ei goes to a path that dereferences ei.
Add another label that skips over the ei dereferences to do the rest of
the clean up.
Link: https://lore.kernel.org/all/70e7bace-561c-95f-1117-706c2c22...@inria.fr/
Fixes: 57
On Thu, 19 Oct 2023 21:18:43 +0900
Masami Hiramatsu (Google) wrote:
> > So why is this adding stable? (and as Greg's form letter states, that's not
> > how you do that)
> >
> > I don't see this as a fix but a new feature.
>
> I asked him to make this a fix since the current kprobe event'
On Wed, 18 Oct 2023 17:40:28 +0300
Francis Laniel wrote:
> Changes since:
> v1:
> * Use EADDRNOTAVAIL instead of adding a new error code.
> * Correct also this behavior for sysfs kprobe.
> v2:
> * Count the number of symbols corresponding to function name and return
> EADDRNOTAVAIL if
On Fri, 13 Oct 2023 12:43:18 -0700
Andrii Nakryiko wrote:
> > Correct. My Ack is based on the current way things are done upstream.
> > It was just that linux-rt showed the issue, where the code was not as
> > robust as it should have been. To me this was a correctness issue, not
> > an issue
On Fri, 13 Oct 2023 15:22:19 +0530
Krishna chaitanya chundru wrote:
> +++ b/include/trace/events/mhi_host.h
> @@ -0,0 +1,287 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#undef TRACE_SYSTEM
>
On Fri, 13 Oct 2023 08:01:34 +0200
Artem Savkov wrote:
> > But looking at [0] and briefly reading some of the discussions you,
> > Steven, had. I'm just wondering if it would be best to avoid
> > increasing struct trace_entry altogether? It seems like preempt_count
> > is actually a 4-bit field
)
> 10492 return -EACCES;
> 10493 }
>
> What bpf program is actually getting is a pointer to struct
> syscall_tp_t, defined in kernel/trace/trace_syscalls.c. This patch fixes
> the problem by aligning struct syscall_tp_t with with struct
> syscall_
On Tue, 10 Oct 2023 22:54:19 +0900
"Masami Hiramatsu (Google)" wrote:
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -912,6 +912,121 @@ static const struct btf_type
> *btf_type_skip_qualifiers(const struct btf *btf,
> return t;
> }
>
> +/*
> + * Find a function proto type by
On Mon, 9 Oct 2023 23:37:14 +0800
Jinyu Tang wrote:
> When we want to know what happened in kernel when our app
> has more latency than we hope, but the larger latency of
> our app may be lower than other process in the syetem.
> We feel sad after waiting a long time but only get other
>
On Mon, 9 Oct 2023 18:58:27 +0800
Yajun Deng wrote:
> > C compiler decides to inline or not, depending on various factors.
> >
> > The most efficient (and small) code is generated by this_cpu_inc()
> > version, allowing the compiler to inline it.
> >
> > If you copy/paste this_cpu_inc() twenty
On Sat, 7 Oct 2023 21:09:00 +0530
Atul Kumar Pant wrote:
> On Sat, Sep 23, 2023 at 11:00:46PM +0530, Atul Kumar Pant wrote:
> > On Thu, Aug 17, 2023 at 10:38:19PM +0530, Atul Kumar Pant wrote:
> > > Fixes typo in a function name.
> > >
> > > Signed-off-by: Atul Kumar Pant
> > > ---
> > >
On Sat, 7 Oct 2023 19:44:45 +0900
Masami Hiramatsu (Google) wrote:
> [...]
> > @@ -118,6 +72,7 @@ static struct dentry *create_file(const char *name,
> > umode_t mode,
> > if (WARN_ON_ONCE(!S_ISREG(mode)))
> > return NULL;
> >
> > + WARN_ON_ONCE(!parent);
>
> Nit: This
On Wed, 4 Oct 2023 22:35:07 +0100
Alan Maguire wrote:
> One thing we've heard from some embedded folks [1] is that having
> kernel BTF loadable as a separate module (rather than embedded in
> vmlinux) would help, as there are size limits on vmlinux that they can
> workaround by having modules on
From: "Steven Rostedt (Google)"
Instead of having a descriptor for every file represented in the eventfs
directory, only have the directory itself represented. Change the API to
send in a list of entries that represent all the files in the directory
(but not other directories). The
On Wed, 04 Oct 2023 20:38:46 +0200
Johannes Berg wrote:
> On Wed, 2023-10-04 at 09:22 -0700, Jakub Kicinski wrote:
> >
> > Potentially naive question - the trace point holds enum skb_drop_reason.
> > The user space can get the names from BTF. Can we not teach user space
> > to generically look
On Wed, 4 Oct 2023 09:54:31 -0700
Jakub Kicinski wrote:
> On Wed, 4 Oct 2023 12:35:24 -0400 Steven Rostedt wrote:
> > > Potentially naive question - the trace point holds enum skb_drop_reason.
> > > The user space can get the names from BTF. Can we not teach user space
>
On Wed, 4 Oct 2023 09:22:05 -0700
Jakub Kicinski wrote:
> Potentially naive question - the trace point holds enum skb_drop_reason.
> The user space can get the names from BTF. Can we not teach user space
> to generically look up names of enums in BTF?
That puts a hard requirement to include BTF
On Wed, 4 Oct 2023 10:39:33 -0400
Nick Lowell wrote:
> > [ cut here ]
> > WARNING: CPU: 5 PID: 944 at kernel/trace/trace_events_filter.c:2423
> > apply_subsystem_event_filter+0x18c/0x5e0
> > Modules linked in:
> > CPU: 5 PID: 944 Comm: trace-cmd Not tainted
> >
On Wed, 4 Oct 2023 16:00:34 +0200
Hans Verkuil wrote:
> > The original patch did have linux-me...@vger.kernel.org Cc'd. Was it
> > dropped?
>
> You are correct, it was sitting in patchwork, I somehow missed it.
>
> It's now delegated to me, so it is in my pipeline.
Thanks a lot! I
On Wed, 4 Oct 2023 08:33:12 +0200
Hans Verkuil wrote:
> On 03/10/2023 23:41, Steven Rostedt wrote:
> >
> > Could this go through the linux-media tree, or if you give it an Ack, I'll
> > take it through the tracing tree.
>
> I prefer to take this through the med
On Wed, 4 Oct 2023 08:17:31 -0400
Steven Rostedt wrote:
> #!/bin/bash
>
> find_debugfs() {
> debugfs=`cat /proc/mounts | while read mount dir type opts a b; do
> if [ $mount == "debugfs" ]; then
I guess I should update this to look for tracefs. This scri
On Wed, 4 Oct 2023 12:02:52 +0200
Daniel Bristot de Oliveira wrote:
> On 10/4/23 03:03, Steven Rostedt wrote:
> > On Fri, 29 Sep 2023 17:02:46 +0200
> > Daniel Bristot de Oliveira wrote:
> >
> >> The osnoise/per_cpu/CPU$/timerlat_fd is create for each possible
On Mon, 2 Oct 2023 10:41:48 -0400
Nicholas Lowell wrote:
> @@ -2411,7 +2418,12 @@ int apply_subsystem_event_filter(struct
> trace_subsystem_dir *dir,
> }
>
> if (!strcmp(strstrip(filter_string), "0")) {
> - filter_free_subsystem_preds(dir, tr);
> + /* If
On Mon, 2 Oct 2023 15:52:42 +0200
Artem Savkov wrote:
> linux-rt-devel tree contains a patch that adds an extra member to struct
> trace_entry. This causes the offset of args field in struct
> trace_event_raw_sys_enter be different from the one in struct
> syscall_trace_enter:
This patch looks
On Fri, 29 Sep 2023 17:02:46 +0200
Daniel Bristot de Oliveira wrote:
> The osnoise/per_cpu/CPU$/timerlat_fd is create for each possible
> CPU, but it might create confusion if the CPU is not online.
>
> Create the file only for online CPUs, also follow hotplug by
> creating and deleting as CPUs
cient full recording
> of DAMOS-based filtered monitoring results.
>
From a tracing point of view.
Reviewed-by: Steven Rostedt (Google)
-- Steve
From: "Steven Rostedt (Google)"
Instead of having a descriptor for every file represented in the eventfs
directory, only have the directory itself represented. Change the API to
send in a list of entries that represent all the files in the directory
(but not other directories). The
901 - 1000 of 34317 matches
Mail list logo
