On 9/30/24 23:43, Masami Hiramatsu (Google) wrote:
On Mon, 30 Sep 2024 11:32:31 -0400
Steven Rostedt wrote:
On Tue, 1 Oct 2024 00:28:13 +0900
Masami Hiramatsu (Google) wrote:
On Mon, 30 Sep 2024 10:06:30 -0400
Steven Rostedt wrote:
On Mon, 30 Sep 2024 09:33:42 +0800
Tiezhu Yang wrote:
On Thu, 26 Sept 2024 at 19:02, Steven Rostedt wrote:
>
> From: Steven Rostedt
>
> At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede
> about the persistent buffer to display traces from previous boots. He
> mentioned that UEFI can clear memory. In my own tests I have not seen
On Mon, 30 Sep 2024 14:46:59 -0400
Steven Rostedt wrote:
> On Tue, 17 Sep 2024 09:26:25 +0100
> Will Deacon wrote:
>
> > On Sun, Sep 15, 2024 at 04:46:14AM -0400, Steven Rostedt wrote:
> > > Can I get an Acked-by from the AARCH64 maintainers for this patch?
> >
> > Sorry, I wasn't CC'd on th
Hi Steve,
Can we revisit this patch? see below.
On Tue, Jan 24, 2023 at 12:17:03PM GMT, Steven Rostedt wrote:
> On Mon, 9 Jan 2023 19:39:21 +0800 (CST)
> wrote:
>
> > From: Xu Panda
> >
> > The implementation of strscpy() is more robust and safer.
> > That's now the recommended way to copy NU
num_buf[len] = 0;
+ strscpy(num_buf, str + s, len);
/* Make sure it is a value */
if (field->is_signed)
---
base-commit: bc83b4d1f08695e85e85d36f7b803da58010161d
change-id: 20240930-strncpy-kernel-trace-trace_events_filter-c-f44a3f848518
Best regards,
--
Justin Stitt
On Sun, Sep 29, 2024 at 1:58 PM Jiri Olsa wrote:
>
> Adding support to attach program in uprobe session mode
> with bpf_program__attach_uprobe_multi function.
>
> Adding session bool to bpf_uprobe_multi_opts struct that allows
> to load and attach the bpf program via uprobe session.
> the attachme
On Sun, Sep 29, 2024 at 1:58 PM Jiri Olsa wrote:
>
> The uprobe and kprobe session program can return only 0 or 1,
> instruct verifier to check for that.
>
> Signed-off-by: Jiri Olsa
> ---
> kernel/bpf/verifier.c | 10 ++
> 1 file changed, 10 insertions(+)
>
Do we need Fixes: tag?
Acke
On Sun, Sep 29, 2024 at 1:58 PM Jiri Olsa wrote:
>
> Adding support to attach BPF program for entry and return probe
> of the same function. This is common use case which at the moment
> requires to create two uprobe multi links.
>
> Adding new BPF_TRACE_UPROBE_SESSION attach type that instructs
>
On Sun, Sep 29, 2024 at 1:57 PM Jiri Olsa wrote:
>
> This change allows the uprobe consumer to behave as session which
> means that 'handler' and 'ret_handler' callbacks are connected in
> a way that allows to:
>
> - control execution of 'ret_handler' from 'handler' callback
> - share data bet
On Sun, Sep 29, 2024 at 1:57 PM Jiri Olsa wrote:
>
> Adding data pointer to both entry and exit consumer handlers and all
> its users. The functionality itself is coming in following change.
>
> Signed-off-by: Jiri Olsa
> ---
> include/linux/uprobes.h | 4 ++--
> ke
On Mon, Sep 30 2024 at 16:53, Jeff Layton wrote:
> On Mon, 2024-09-30 at 22:19 +0200, Thomas Gleixner wrote:
>> On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
>> > If however, two threads have racing syscalls that overlap in time, then
>> > there
>> > is no such guarantee,
This patch switches uprobes SRCU usage to RCU Tasks Trace flavor, which
is optimized for more lightweight and quick readers (at the expense of
slower writers, which for uprobes is a fine trade-off) and has better
performance and scalability with number of CPUs.
Similarly to baseline vs SRCU, we've
On Fri, Sep 27, 2024 at 2:56 AM Liao Chang wrote:
>
> The uprobe handler allocates xol slot from xol_area and quickly release
> it in the single-step handler. The atomic operations on the xol bitmap
> and slot_count lead to expensive cache line bouncing between multiple
> CPUs. Given the xol slot
On Mon, 2024-09-30 at 22:19 +0200, Thomas Gleixner wrote:
> On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
> > On Mon, 2024-09-30 at 21:16 +0200, Thomas Gleixner wrote:
> > I have the following section in the multigrain-ts.rst file that gets
> > added in patch 7 of this series. I'll also plan to
When creating a trace_probe we would set nr_args prior to truncating the
arguments to MAX_TRACE_ARGS. However, we would only initialize arguments
up to the limit.
This caused invalid memory access when attempting to set up probes with
more than 128 fetchargs.
BUG: kernel NULL pointer dereferenc
On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
> On Mon, 2024-09-30 at 21:16 +0200, Thomas Gleixner wrote:
> I have the following section in the multigrain-ts.rst file that gets
> added in patch 7 of this series. I'll also plan to add some extra
> wording about how backward realtime clock jumps c
On Mon, Sep 30 2024 at 15:27, Jeff Layton wrote:
> On Mon, 2024-09-30 at 21:13 +0200, Thomas Gleixner wrote:
>> So if that's the intended behaviour then the changelog is misleading at
>> best.
>
> That is the intended behavior and I'll plan to fix the changelog to
> clarify this point:
>
> If someo
On Mon, 2024-09-30 at 21:43 +0200, Thomas Gleixner wrote:
> On Thu, Sep 19 2024 at 18:50, Jeff Layton wrote:
> > The fix for this is to establish a floor value for the coarse-grained
> > clock. When stamping a file with a fine-grained timestamp, we update
> > the floor value with the current monoto
Use Tasks Trace RCU to protect iteration of system call enter/exit
tracepoint probes to allow those probes to handle page faults.
In preparation for this change, all tracers registering to system call
enter/exit tracepoints should expect those to be called with preemption
enabled.
This allows tra
In preparation for allowing system call enter/exit instrumentation to
handle page faults, make sure that bpf can handle this change by
explicitly disabling preemption within the bpf system call tracepoint
probes to respect the current expectations within bpf tracing code.
This change does not yet
In preparation for allowing system call tracepoints to handle page
faults, introduce TRACE_EVENT_SYSCALL to declare the sys_enter/sys_exit
tracepoints.
Emit the static inlines register_trace_syscall_##name for events
declared with TRACE_EVENT_SYSCALL, allowing source-level validation
that only pro
On Thu, Sep 19 2024 at 18:50, Jeff Layton wrote:
> The fix for this is to establish a floor value for the coarse-grained
> clock. When stamping a file with a fine-grained timestamp, we update
> the floor value with the current monotonic time (using cmpxchg). Then
> later, when a coarse-grained time
Add a might_fault() check to validate that the perf sys_enter/sys_exit
probe callbacks are indeed called from a context where page faults can
be handled.
Signed-off-by: Mathieu Desnoyers
Cc: Michael Jeanson
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Alexei Starovoitov
Cc:
Add a might_fault() check to validate that the bpf sys_enter/sys_exit
probe callbacks are indeed called from a context where page faults can
be handled.
Signed-off-by: Mathieu Desnoyers
Acked-by: Andrii Nakryiko
Tested-by: Andrii Nakryiko # BPF parts
Cc: Michael Jeanson
Cc: Steven Rostedt
Cc:
In preparation for allowing system call enter/exit instrumentation to
handle page faults, make sure that ftrace can handle this change by
explicitly disabling preemption within the ftrace system call tracepoint
probes to respect the current expectations within ftrace ring buffer
code.
This change
On Mon, 2024-09-30 at 21:16 +0200, Thomas Gleixner wrote:
> On Mon, Sep 16 2024 at 06:57, Jeff Layton wrote:
> > On Mon, 2024-09-16 at 12:32 +0200, Thomas Gleixner wrote:
> > > > 'Something has changed' is a truly understandable technical
> > > > explanation.
> > >
> > > old = mg_floor
> > >
In preparation for allowing system call enter/exit instrumentation to
handle page faults, make sure that perf can handle this change by
explicitly disabling preemption within the perf system call tracepoint
probes to respect the current expectations within perf ring buffer code.
This change does n
On Mon, 2024-09-30 at 21:13 +0200, Thomas Gleixner wrote:
> On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
>
> > For multigrain timestamps, we must keep track of the latest timestamp
> > that has ever been handed out, and never hand out a coarse time below
> > that value.
>
> How is that correc
Add a might_fault() check to validate that the ftrace sys_enter/sys_exit
probe callbacks are indeed called from a context where page faults can
be handled.
Signed-off-by: Mathieu Desnoyers
Acked-by: Masami Hiramatsu (Google)
Cc: Michael Jeanson
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Pete
Wire up the system call tracepoints with Tasks Trace RCU to allow
the ftrace, perf, and eBPF tracers to handle page faults.
This series does the initial wire-up allowing tracers to handle page
faults, but leaves out the actual handling of said page faults as future
work.
This series was compile a
On Mon, Sep 16 2024 at 06:57, Jeff Layton wrote:
> On Mon, 2024-09-16 at 12:32 +0200, Thomas Gleixner wrote:
>> > 'Something has changed' is a truly understandable technical
>> > explanation.
>>
>> old = mg_floor
>> mono = T1;
>>
On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
> For multigrain timestamps, we must keep track of the latest timestamp
> that has ever been handed out, and never hand out a coarse time below
> that value.
How is that correct when the clock is off by an hour and then set back
to the correct valu
On Tue, 17 Sep 2024 11:08:48 +0100
Will Deacon wrote:
> > > @@ -787,6 +789,9 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs,
> > > unsigned long frame_pointe
> > > }
> > >
> > > trace.rettime = trace_clock_local();
> > > + if (fregs)
> > > + ftrace_regs_set_instruction_poi
On Tue, 17 Sep 2024 10:55:39 +0100
Will Deacon wrote:
> The arm64 part looks good to me, although passing a partially-populated
> struct out of asm feels like it's going to cause us hard-to-debug
> problems down the line if any of those extra fields get used. How hard
> would it be to poison the
On Tue, 17 Sep 2024 09:26:25 +0100
Will Deacon wrote:
> On Sun, Sep 15, 2024 at 04:46:14AM -0400, Steven Rostedt wrote:
> > Can I get an Acked-by from the AARCH64 maintainers for this patch?
>
> Sorry, I wasn't CC'd on the thread, so I missed this.
Here's the lore link that starts it all:
On Mon, 30 Sep 2024 11:20:48 -0600
Jonathan Corbet wrote:
> > And I forgot to send this to the Documentation maintainers :-p
> >
> > Jon, could you take this? Do you need me to resend, or can you just pull it
> > from lore?
>
> I'll grab it in a bit.
No rush.
Thanks!
-- Steve
Steven Rostedt writes:
> On Thu, 26 Sep 2024 19:54:48 +0200
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 26-Sep-24 7:01 PM, Steven Rostedt wrote:
>> > From: Steven Rostedt
>> >
>> > At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede
>> > about the persistent buffer to display
On Thu, 26 Sep 2024 19:54:48 +0200
Hans de Goede wrote:
> Hi,
>
> On 26-Sep-24 7:01 PM, Steven Rostedt wrote:
> > From: Steven Rostedt
> >
> > At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede
> > about the persistent buffer to display traces from previous boots. He
> > m
On Mon, 30 Sep 2024 11:32:31 -0400
Steven Rostedt wrote:
> On Tue, 1 Oct 2024 00:28:13 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Mon, 30 Sep 2024 10:06:30 -0400
> > Steven Rostedt wrote:
> >
> > > On Mon, 30 Sep 2024 09:33:42 +0800
> > > Tiezhu Yang wrote:
> > >
> > > > > the CONF
On Sun, 29 Sep 2024 23:17:14 -0400
Mikel Rychliski wrote:
> On Sunday, September 29, 2024 7:40:18 P.M. EDT Masami Hiramatsu wrote:
> > Good catch! But this silently drop the arguments after MAX_TRACE_ARGS.
> > I rather like to reject such input with an error (-E2BIG) as below.
> > (Hmm, and I als
On Tue, 1 Oct 2024 00:28:13 +0900
Masami Hiramatsu (Google) wrote:
> On Mon, 30 Sep 2024 10:06:30 -0400
> Steven Rostedt wrote:
>
> > On Mon, 30 Sep 2024 09:33:42 +0800
> > Tiezhu Yang wrote:
> >
> > > > the CONFIG_UPROBES is disabled by default and make CONFIG_UPROBE_EVENTS
> > > > dependi
On Mon, 30 Sep 2024 10:06:30 -0400
Steven Rostedt wrote:
> On Mon, 30 Sep 2024 09:33:42 +0800
> Tiezhu Yang wrote:
>
> > > the CONFIG_UPROBES is disabled by default and make CONFIG_UPROBE_EVENTS
> > > depending on it, the uprobe_events menu is hidden. I don't like this.
> >
> > This is someh
On Mon, 30 Sep 2024 18:16:01 +0530
Maverickk 78 wrote:
> Hello,
>
> I enabled ftrace and set a filter on the command line as *pcie*, I
> dont see some of the pciehp(eg: pciehp_probe from pciehp_core.c)
> module function calls in ftrace, It does trace pciehp_isr but nothing
> else.
>
> My comman
On Mon, 30 Sep 2024 13:21:07 +0200
Julia Lawall wrote:
> Reorganize kerneldoc parameter names to match the parameter
> order in the function header.
>
> Problems identified using Coccinelle.
>
> Signed-off-by: Julia Lawall
Acked-by: Steven Rostedt (Google)
-- Steve
>
> ---
> kernel/trace
On Mon, 30 Sep 2024 07:10:31 +
Liao Chang wrote:
> This patch uses [first ... last] = value to initialize fgraph_array[].
> And use fgraph_lru_next and fgraph_lru_last as the indicator of
> initialization.
The only thing this patch does is to allow the use of [first...last]
annotation for in
On Sun, 29 Sep 2024 23:21:05 +
furkanonder wrote:
> I’m sorry; I included the patch as an attachment in the email without
> noticing.
Yes, but still, you need to have the patch with the change log and the
signed-off-by. Not as a separate email.
Try using "git send-email", that can probably
On Mon, 30 Sep 2024 09:33:42 +0800
Tiezhu Yang wrote:
> > the CONFIG_UPROBES is disabled by default and make CONFIG_UPROBE_EVENTS
> > depending on it, the uprobe_events menu is hidden. I don't like this.
>
> This is somehow like the current status of CONFIG_KPROBES and
> CONFIG_KPROBE_EVENTS.
On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini wrote:
>
>
>
> On 17/09/24 1:20 pm, Alexei Starovoitov wrote:
> > On Sun, Sep 15, 2024 at 10:58 PM Hari Bathini
> > wrote:
> >>
> >> +
> >> + /*
> >> +* Generated stack layout:
> >> +*
> >> +* func prev back chain
Hello,
I enabled ftrace and set a filter on the command line as *pcie*, I
dont see some of the pciehp(eg: pciehp_probe from pciehp_core.c)
module function calls in ftrace, It does trace pciehp_isr but nothing
else.
My command line is "ftrace=function_graph ftrace_graph_filter=*pcie*
", is there a
On Mon, Sep 30, 2024 at 11:40:15AM +0200, Oleg Nesterov wrote:
> Jiri,
>
> LGTM. But I'm afraid you need to send v6, sorry ;)
>
> This change has some (trivial) conflicts in prepare_uretprobe() with the
> cleanups I sent yesterday, and Peter is going to queue them.
sure, np.. will wait for any r
Reorganize kerneldoc parameter names to match the parameter
order in the function header.
Problems identified using Coccinelle.
Signed-off-by: Julia Lawall
---
kernel/trace/ring_buffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/
Reorganize kerneldoc parameter names to match the parameter
order in the function header.
The misordered cases were identified using the following
Coccinelle semantic patch:
//
@initialize:ocaml@
@@
let parse_doc l =
let pieces = List.map String.trim (String.split_on_char '*' l) in
let l =
Jiri,
LGTM. But I'm afraid you need to send v6, sorry ;)
This change has some (trivial) conflicts in prepare_uretprobe() with the
cleanups I sent yesterday, and Peter is going to queue them.
See https://lore.kernel.org/all/20240929144201.ga9...@redhat.com/
Oleg.
On 09/29, Jiri Olsa wrote:
>
>
On 09/29, Jiri Olsa wrote:
>
> Adding data pointer to both entry and exit consumer handlers and all
> its users. The functionality itself is coming in following change.
>
> Signed-off-by: Jiri Olsa
Acked-by: Oleg Nesterov
On Sun, Sep 29, 2024 at 04:42:01PM +0200, Oleg Nesterov wrote:
> Hello,
>
> No functional changes, please review.
>
> I'd like to push these cleanups first, then I'll send some optimizations
> on top of this series.
They look okay to me, I'll queue them up. Thanks!
This patch uses [first ... last] = value to initialize fgraph_array[].
And use fgraph_lru_next and fgraph_lru_last as the indicator of
initialization.
v2->v1:
Fixup the build error reported by kernel test robot .
Since some architectures use ftrace_graph_entry_stub() for the static
ftrace scenario
在 2024/9/28 8:17, Steven Rostedt 写道:
> On Thu, 12 Sep 2024 11:15:50 +
> Liao Chang wrote:
>
>> This patch uses [first ... last] = value to initialize fgraph_array[].
>> And it declares all the callbacks in fgraph_stub as static, as they are
>> not called from external code.
>
> This patch
57 matches
Mail list logo
