On Mon, 21 Oct 2024 12:24:29 +0200
Gianfranco Trad wrote:
> Coverity reports unused assignment to value ret. [1]
> ret is assigned to 0 here, but that stored value is overwritten before
> it can be used. The overwrite might happen either at line 1277, 1290
> or eventually at line 1306. Therefore
在 2024/10/22 1:18, Andrii Nakryiko 写道:
> On Mon, Oct 21, 2024 at 3:43 AM Liao, Chang wrote:
>>
>>
>>
>> 在 2024/10/12 3:34, Andrii Nakryiko 写道:
>>> On Tue, Sep 17, 2024 at 7:05 PM Liao, Chang wrote:
Hi, Peter and Masami
I look forward to your inputs on these series. Andrii h
Hi Steve,
On 22/10/2024 07:28, Steven Rostedt wrote:
On Mon, 21 Oct 2024 11:44:42 +0200
Jean-Michel Hautbois wrote:
The TRACE_IRQFLAGS_SUPPORT requires the architecture to call
trace_hardirqs_off() when interrupts are disabled and
trace_hardirqs_on() when they are enabled.
Add those calls to
Hi,
On Thu, 5 Sep 2024 00:19:16 +0200
"Fernando F. Mancera" wrote:
> Hi,
>
> On 26/08/2024 01:56, Masami Hiramatsu (Google) wrote:
> > On Sun, 25 Aug 2024 19:06:22 +0200
> > "Fernando F. Mancera" wrote:
> >
> >> Hi,
> >>
> >> On 25/08/2024 09:41, Masami Hiramatsu (Google) wrote:
> >>> Hi,
> >
On Mon, 21 Oct 2024 11:44:42 +0200
Jean-Michel Hautbois wrote:
> The TRACE_IRQFLAGS_SUPPORT requires the architecture to call
> trace_hardirqs_off() when interrupts are disabled and
> trace_hardirqs_on() when they are enabled.
> Add those calls to do_IRQ function.
>
> Signed-off-by: Jean-Michel
On Mon, 26 Aug 2024 08:07:18 +0200
Viktor Malik wrote:
> objpool intends to use vmalloc for default (non-atomic) allocations of
> percpu slots and objects. However, the condition checking if GFP flags
> are equal to GFP_ATOMIC is wrong b/c GFP_ATOMIC is a combination of bits
You meant "whether G
On Thu, 15 Aug 2024 01:46:28 +
Liao Chang wrote:
> Since clearing a bit in thread_info is an atomic operation, the spinlock
> is redundant and can be removed, reducing lock contention is good for
> performance.
>
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thanks!
> Acked-by:
Hi Liao,
On Thu, 15 Aug 2024 01:46:29 +
Liao Chang wrote:
> This patch introduces a flag to track TIF_SIGPENDING is suppress
> temporarily during the uprobe single-step. Upon uprobe singlestep is
> handled and the flag is confirmed, it could resume the TIF_SIGPENDING
> directly without acqui
On Tue, 22 Oct 2024 11:22:22 +0900
Masami Hiramatsu (Google) wrote:
> On Wed, 31 Jul 2024 16:12:32 +0200
> Oleg Nesterov wrote:
>
> > On 07/31, Liao Chang wrote:
> > >
> > > --- a/kernel/events/uprobes.c
> > > +++ b/kernel/events/uprobes.c
> > > @@ -1979,9 +1979,7 @@ bool uprobe_deny_signal(voi
On Mon, 21 Oct 2024 14:58:10 +0900
Masami Hiramatsu (Google) wrote:
> > + if (!fgraph_initialized) {
> > + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
> > "fgraph_idle_init",
>
> Nit: Maybe it is better to call it as "tracing/fgraph:online" ?
Ah this already went upstream. But y
On Monday, September 30, 2024 4:26:54 P.M. EDT Mikel Rychliski wrote:
> V1 -> V2: Return error instead of dropping excessive arguments
Hi Masami,
Thanks for the feedback so far. Was wondering if you had a chance to look at
the updated patch?
Thanks,
Mikel
On Wed, 31 Jul 2024 16:12:32 +0200
Oleg Nesterov wrote:
> On 07/31, Liao Chang wrote:
> >
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -1979,9 +1979,7 @@ bool uprobe_deny_signal(void)
> > WARN_ON_ONCE(utask->state != UTASK_SSTEP);
> >
> > if (task_sigpendin
On Tue, 2024-07-30 at 07:13 -0700, Randy Dunlap wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> Hi--
>
> On 7/30/24 1:24 AM, Liju-clr Chen wrote:
> > From: Yingshiuan Pan
> >
> > GenieZone is MediaTek propr
alid opcode: [#1] PREEMPT SMP NOPTI
[0.885434] CPU: 3 UID: 0 PID: 157 Comm: modprobe Tainted: G W
6.12.0-rc3-debug-next-20241021-06324-g63b3ff03d91a #1
291f0fd70f293827edec681d3c5304f5807a3c7b
[0.887084] Tainted: [W]=WARN
[0.887409] Hardware name: QEMU Standar
The function simple_strtoul performs no error checking in scenarios
where the input value overflows the intended output variable.
This results in this function successfully returning, even when the
output does not match the input string (aka the function returns
successfully even when the result is
The simple_str* family of functions perform no error checking in
scenarios where the input value overflows the intended output variable.
This results in these functions successfully returning even when the
output does not match the input string.
Or as it was mentioned [1], "...simple_strtol(), sim
The simple_str* family of functions perform no error checking in
scenarios where the input value overflows the intended output variable.
This results in these function successfully returning even when the
output does not match the input string.
Or as it was mentioned [1], "...simple_strtol(), simp
I performed a bisection and this issue starts with commit a363d27cdbc2
("tracing: Allow system call tracepoints to handle page faults") which
introduces this change.
> + *
> + * With @syscall=0, the tracepoint callback array dereference is
> + * protected by disabling preemption.
> + * With @sysca
On Mon, Oct 21, 2024 at 3:43 AM Liao, Chang wrote:
>
>
>
> 在 2024/10/12 3:34, Andrii Nakryiko 写道:
> > On Tue, Sep 17, 2024 at 7:05 PM Liao, Chang wrote:
> >>
> >> Hi, Peter and Masami
> >>
> >> I look forward to your inputs on these series. Andrii has proven they are
> >> hepful for uprobe scalab
On Mon, Oct 21, 2024 at 3:31 AM Peter Zijlstra wrote:
>
> On Fri, Oct 18, 2024 at 11:22:00AM -0700, Andrii Nakryiko wrote:
> > On Fri, Oct 18, 2024 at 1:26 AM Peter Zijlstra wrote:
> > >
> > > On Mon, Oct 07, 2024 at 05:25:55PM -0700, Andrii Nakryiko wrote:
> > > > Currently put_uprobe() might tr
On Wed, Oct 16, 2024 at 09:57:55AM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Pass ftrace_regs to the fgraph_ops::entryfunc(). If ftrace_regs is not
> available, it passes a NULL instead. User callback function can access
> some registers (including return addre
On Wed, Oct 16, 2024 at 09:59:12AM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Add ftrace_fill_perf_regs() which should be compatible with the
> perf_fetch_caller_regs(). In other words, the pt_regs returned from the
> ftrace_fill_perf_regs() must satisfy 'user_m
On Mon, Oct 21, 2024 at 3:48 AM Peter Zijlstra wrote:
>
> On Fri, Oct 18, 2024 at 11:22:09AM -0700, Andrii Nakryiko wrote:
>
> > > So... after a few readings I think I'm mostly okay with this. But I got
> > > annoyed by the whole HPROBE_STABLE with uprobe=NULL weirdness. Also,
> > > that data_race
On Wed, Oct 16, 2024 at 09:59:00AM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Add ftrace_partial_regs() which converts the ftrace_regs to pt_regs.
> This is for the eBPF which needs this to keep the same pt_regs interface
> to access registers.
> Thus when repla
On Wed, Oct 16, 2024 at 09:58:09AM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Use ftrace_regs instead of fgraph_ret_regs for tracing return value
> on function_graph tracer because of simplifying the callback interface.
>
> The CONFIG_HAVE_FUNCTION_GRAPH_RETVAL
> > Please note that this only works for addresses in the kernel address
> > space. For user space the full 64 bit address range (minus the top
> > page) can be used for user space applications.
>
> I wonder what is the unsigned long size (stack entry size) of the
> s390? is it 64bit?
The s390 ke
The variable `ret` is assigned a value which is unused.
Fix this by removing the redundant `ret = 0;` assignment.
This issue was reported by Coverity Scan.
Report:
CID 1600916: (#1 of 1): Unused value (UNUSED_VALUE)
assigned_value: Assigning value 0 to ret here,
but that stored value is overwritte
The enhancements made to timerlat_load.py are intended to improve the script's
exception handling.
Summary of the changes:
- Specific exceptions are now caught for CPU affinity and priority
settings, with clearer error messages provided.
- The timerlat file descriptor opening now includes
The enhancements made to timerlat_load.py are aimed at improving the clarity of
argument parsing.
Summary of Changes:
- The cpu argument is now specified as an integer type in the argument
parser to enforce input validation, and the construction of affinity_mask
has been simplified to directl
This is a followup to PeterZ'
https://lore.kernel.org/20241007074609.447006...@infradead.org
in PREEMPT_RT we had initially "LAZY preempt" this then morphed into
PREEMPT_AUTO and is becoming "Lazy preemption".
These are the tracing bits from that time that were used up to
PREEMPT_AUTO. Wit
The enhancements made to timerlat_load.py are intended to improve the
script's robustness and readability.
Summary of the changes:
- Unnecessary semicolons at the end of lines have been removed.
- Parentheses surrounding the if statement checking args.prio have been
eliminated.
- String concatenat
On Fri, 18 Oct 2024 14:49:52 +0200
Heiko Carstens wrote:
> On Wed, Oct 16, 2024 at 10:10:22AM -0400, Steven Rostedt wrote:
> > On Wed, 16 Oct 2024 14:07:31 +0200
> > Sven Schnelle wrote:
> > > I haven't yet fully understood why this logic is needed, but the
> > > WARN_ON_ONCE triggers on s390. I
From: Thomas Gleixner
The scheduler added NEED_RESCHED_LAZY scheduling. Record this state as
part of trace flags and expose it in the need_resched field.
Record and expose NEED_RESCHED_LAZY.
[bigeasy: Commit description, documentation bits.]
Reviewed-by: Ankur Arora
Reviewed-by: Steven Rosted
From: Jisheng Zhang
riscv has switched to GENERIC_ENTRY, so adding PREEMPT_LAZY is as simple
as adding TIF_NEED_RESCHED_LAZY related definitions and enabling
ARCH_HAS_PREEMPT_LAZY.
[bigeasy: Replace old PREEMPT_AUTO bits with new PREEMPT_LAZY ]
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: Albert
From: Thomas Gleixner
The TRACE_FLAG_IRQS_NOSUPPORT flag is used by tracing_gen_ctx.*() to
signal that CONFIG_TRACE_IRQFLAGS_SUPPORT is not enabled and tracing IRQ
flags is not supported.
This could be replaced by using the 0 as flags and then deducting that
there is no IRQFLAGS_SUPPORT based on
On Sat, 19 Oct 2024 15:29:51 -0400
Steven Rostedt wrote:
> From: Steven Rostedt
>
> The ret_stack (shadow stack used by function graph infrastructure) is
> currently defined as PAGE_SIZE. But some architectures which have 64K
> PAGE_SIZE, this is way overkill. Also there's an effort to allow th
On 10/21/24 06:38, Robin Murphy wrote:
> On 2024-10-17 7:13 pm, Sean Anderson wrote:
>> It can be surprising to the user if DMA functions are only traced on
>> success. On failure, it can be unclear what the source of the problem
>> is. Fix this by tracing all functions even when they fail. Cases w
Previously the size of "struct ftrace_stacks" depended upon PAGE_SIZE.
For the common 4K page size, on a 64-bit system, sizeof(struct
ftrace_stacks) was 32K. But for a 64K page size, sizeof(struct
ftrace_stacks) was 512K.
But ftrace stack usage requirements should be invariant to page size. So
let
On Tue, 13 Aug 2024 19:53:31 +0800
Jinjie Ruan wrote:
> Annotate structs with __counted_by() for kprobe and do some cleanup.
>
> Jinjie Ruan (3):
> kprobes: Annotate structs with __counted_by()
> kprobes: Cleanup the config comment
> kprobes: Cleanup collect_one_slot() and __disable_kprobe
On Mon, Oct 21, 2024 at 12:48:15PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 18, 2024 at 11:22:09AM -0700, Andrii Nakryiko wrote:
>
> > > So... after a few readings I think I'm mostly okay with this. But I got
> > > annoyed by the whole HPROBE_STABLE with uprobe=NULL weirdness. Also,
> > > that d
From: Masami Hiramatsu (Google)
Cleanup kprobes on ftrace code for x86.
- Set instruction pointer (ip + MCOUNT_INSN_SIZE) after pre_handler only
when p->post_handler exists.
- Use INT3_INSN_SIZE instead of 1.
- Use instruction_pointer/instruction_pointer_set() functions instead of
access
From: Tomas Glozar
Since commit fb9e90a67ee9 ("rtla/timerlat: Make user-space threads
the default"), rtla-timerlat has been defaulting to
params->user_workload if neither that or params->kernel_workload is set.
This has unintentionally made -U, which sets only params->user_hist/top
but not params
在 2024/10/1 22:29, Oleg Nesterov 写道:
> On 09/27, 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
>> C
Oleg,
My bad to take so long to reply. I have recently returned from a long vacation.
在 2024/9/28 1:18, Oleg Nesterov 写道:
> On 09/27, Liao Chang wrote:
>>
>> +int recycle_utask_slot(struct uprobe_task *utask, struct xol_area *area)
>> +{
>> +int slot = UINSNS_PER_PAGE;
>> +
>> +/*
>> +
在 2024/10/10 18:52, Mark Rutland 写道:
> On Mon, Sep 09, 2024 at 07:11:14AM +, Liao Chang wrote:
>> v2->v1:
>> 1. Remove the simuation of STP and the related bits.
>> 2. Use arm64_skip_faulting_instruction for single-stepping or FEAT_BTI
>>scenario.
>>
>> As Andrii pointed out, the uprobe/
On Fri, Oct 18, 2024 at 11:22:09AM -0700, Andrii Nakryiko wrote:
> > So... after a few readings I think I'm mostly okay with this. But I got
> > annoyed by the whole HPROBE_STABLE with uprobe=NULL weirdness. Also,
> > that data_race() usage is weird, what is that about?
>
> People keep saying tha
在 2024/10/16 2:58, Catalin Marinas 写道:
> On Mon, 09 Sep 2024 07:11:14 +, Liao Chang wrote:
>> v2->v1:
>> 1. Remove the simuation of STP and the related bits.
>> 2. Use arm64_skip_faulting_instruction for single-stepping or FEAT_BTI
>>scenario.
>>
>> As Andrii pointed out, the uprobe/uret
在 2024/10/12 3:34, Andrii Nakryiko 写道:
> On Tue, Sep 17, 2024 at 7:05 PM Liao, Chang wrote:
>>
>> Hi, Peter and Masami
>>
>> I look forward to your inputs on these series. Andrii has proven they are
>> hepful for uprobe scalability.
>>
>> Thanks.
>>
>> 在 2024/9/15 23:18, Oleg Nesterov 写道:
>>> H
On 2024-10-17 7:13 pm, Sean Anderson wrote:
It can be surprising to the user if DMA functions are only traced on
success. On failure, it can be unclear what the source of the problem
is. Fix this by tracing all functions even when they fail. Cases where
we BUG/WARN are skipped, since those should
On Fri, Oct 18, 2024 at 11:22:00AM -0700, Andrii Nakryiko wrote:
> On Fri, Oct 18, 2024 at 1:26 AM Peter Zijlstra wrote:
> >
> > On Mon, Oct 07, 2024 at 05:25:55PM -0700, Andrii Nakryiko wrote:
> > > Currently put_uprobe() might trigger mutex_lock()/mutex_unlock(), which
> > > makes it unsuitable
Coverity reports unused assignment to value ret. [1]
ret is assigned to 0 here, but that stored value is overwritten before
it can be used. The overwrite might happen either at line 1277, 1290
or eventually at line 1306. Therefore, cleanup the unused assignment.
[1] Coverity Scan, CID 168
Si
In order to use tracing, implement a basic arch_stack_walk() based on
the one in PowerPC.
Tested on a M54418 coldfire.
Signed-off-by: Jean-Michel Hautbois
---
arch/m68k/Kconfig | 5
arch/m68k/kernel/Makefile | 1 +
arch/m68k/kernel/stacktrace.c | 70 +++
The TRACE_IRQFLAGS_SUPPORT requires the architecture to call
trace_hardirqs_off() when interrupts are disabled and
trace_hardirqs_on() when they are enabled.
Add those calls to do_IRQ function.
Signed-off-by: Jean-Michel Hautbois
---
arch/m68k/Kconfig | 1 +
arch/m68k/kernel/irq.c | 2 ++
2
++
arch/m68k/kernel/stacktrace.c | 70 +++
4 files changed, 79 insertions(+)
---
base-commit: 42f7652d3eb527d03665b09edac47f85fb600924
change-id: 20241021-add-m68k-tracing-support-36c18d2233d8
Best regards,
--
Jean-Michel Hautbois
On 21/10/2024 09:37, Steven Rostedt wrote:
> On Mon, 21 Oct 2024 08:58:11 +0100
> Ryan Roberts wrote:
>
>>> @@ -1290,6 +1305,16 @@ int register_ftrace_graph(struct fgraph_ops *gops)
>>>
>>> mutex_lock(&ftrace_lock);
>>>
>>> + if (!fgraph_stack_cachep)
>>> + fgraph_stack_cachep
On Mon, 21 Oct 2024 08:58:11 +0100
Ryan Roberts wrote:
> > @@ -1290,6 +1305,16 @@ int register_ftrace_graph(struct fgraph_ops *gops)
> >
> > mutex_lock(&ftrace_lock);
> >
> > + if (!fgraph_stack_cachep)
> > + fgraph_stack_cachep = kmem_cache_create("fgraph_stack",
> > +
Hi Jinjie,
Sorry for reviewing so late. I have some comments below.
On Tue, 18 Jun 2024 11:52:42 +0800
Jinjie Ruan wrote:
> Add support for kprobes on ftrace call sites to avoid much of the overhead
> with regular kprobes. Try it with simple steps:
>
> cd /sys/kernel/debug/tracing/
>
ne 20. 10. 2024 v 22:01 odesílatel furkanonder
napsal:
>
> The enhancements made to timerlat_load.py are intended to improve the
> script's robustness and readability.
>
> Summary of the changes:
> - Unnecessary semicolons at the end of lines have been removed.
> - Parentheses surrounding the if s
On 19/10/2024 20:29, Steven Rostedt wrote:
> From: Steven Rostedt
>
> The ret_stack (shadow stack used by function graph infrastructure) is
> currently defined as PAGE_SIZE. But some architectures which have 64K
> PAGE_SIZE, this is way overkill. Also there's an effort to allow the
> PAGE_SIZE to
On 19/10/2024 20:27, Steven Rostedt wrote:
> From: Steven Rostedt
>
> The ret_stack (shadow stack used by function graph infrastructure) is
> created for every task on the system when function graph is enabled. Give
> it its own kmem_cache. This will make it easier to see how much memory is
> bei
On Fri, 18 Oct 2024 21:52:12 -0400
Steven Rostedt wrote:
> From: Steven Rostedt
>
> The ret_stack_list is an array of ret_stack shadow stacks for the function
> graph usage. When the first function graph is enabled, all tasks in the
> system get a shadow stack. The ret_stack_list is a 32 elemen
The issue that unrelated function name is shown on stack trace like
following even though it should be trampoline code address is caused by
the creation of trampoline code in the area where .init.text section
of module was freed after module is loaded.
bash-1344[002] .43.644608:
=> (M
62 matches
Mail list logo
