From: Peilin He
Introduce a tracepoint for icmp_send, which can help users to get more
detail information conveniently when icmp abnormal events happen.
1. Giving an usecase example:
=
When an application experiences packet loss due to an unreachable UDP
destination p
On Fri, May 03, 2024 at 10:39:21PM +0200, Jiri Olsa wrote:
> On Fri, May 03, 2024 at 11:03:24AM -0700, Andrii Nakryiko wrote:
> > On Thu, May 2, 2024 at 1:04 PM Jiri Olsa wrote:
> > >
> > > On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote:
> > > > On Thu, May 2, 2024 at 5:23 AM Jiri
On Tue, 7 May 2024 15:41:03 +0800 (CST)
wrote:
> From: Peilin He
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an applicatio
On 2024-05-06 13:00:39 [+0200], Daniel Wagner wrote:
> Hi Sebastian,
Hi Daniel,
> On 06.05.24 12:46, Daniel Wagner wrote:
> > Dear RT Folks,
> >
> > This is the RT stable review cycle of patch 4.19.312-rt134-rc2.
> >
> > Please scream at me if I messed something up. Please test the patches
> > t
hi,
as part of the effort on speeding up the uprobes [0] coming with
return uprobe optimization by using syscall instead of the trap
on the uretprobe trampoline.
The speed up depends on instruction type that uprobe is installed
and depends on specific HW type, please check patch 1 for details.
Pa
Wiring up uretprobe system call, which comes in following changes.
We need to do the wiring before, because the uretprobe implementation
needs the syscall number.
Note at the moment uretprobe syscall is supported only for native
64-bit process.
Reviewed-by: Oleg Nesterov
Reviewed-by: Masami Hira
Adding uretprobe syscall instead of trap to speed up return probe.
At the moment the uretprobe setup/path is:
- install entry uprobe
- when the uprobe is hit, it overwrites probed function's return address
on stack with address of the trampoline that contains breakpoint
instruction
Add uretprobe syscall test that compares register values before
and after the uretprobe is hit. It also compares the register
values seen from attached bpf program.
Acked-by: Andrii Nakryiko
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri Olsa
---
tools/include/linux/compiler.h
Adding test that creates uprobe consumer on uretprobe which changes some
of the registers. Making sure the changed registers are propagated to the
user space when the ureptobe syscall trampoline is used on x86_64.
To be able to do this, adding support to bpf_testmod to create uprobe via
new attrib
Adding test to verify that when called from outside of the
trampoline provided by kernel, the uretprobe syscall will cause
calling process to receive SIGILL signal and the attached bpf
program is not executed.
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri Olsa
---
.../selftests/bpf
Adding return uprobe support to work with enabled shadow stack.
Currently the application with enabled shadow stack will crash
if it sets up return uprobe. The reason is the uretprobe kernel
code changes the user space task's stack, but does not update
shadow stack accordingly.
Adding new functio
Adding return uprobe test for shadow stack and making sure it's
working properly. Borrowed some of the code from bpf selftests.
Signed-off-by: Jiri Olsa
---
.../testing/selftests/x86/test_shadow_stack.c | 142 ++
1 file changed, 142 insertions(+)
diff --git a/tools/testing/selft
Adding man page for new uretprobe syscall.
Signed-off-by: Jiri Olsa
---
man2/uretprobe.2 | 50
1 file changed, 50 insertions(+)
create mode 100644 man2/uretprobe.2
diff --git a/man2/uretprobe.2 b/man2/uretprobe.2
new file mode 100644
index 0
Hi Sebastian,
On Tue, May 07, 2024 at 11:54:07AM GMT, Sebastian Andrzej Siewior wrote:
> I compared mine outcome vs v4.19-rt-next and the diff at the bottom came
> out:
>
> - timer_delete_sync() used to have "#if 0" block around
> lockdep_assert_preemption_enabled() because the function is not
On Tue 2024-05-07 13:01:11, zhangwar...@gmail.com wrote:
> From: Wardenjohn
>
> The original macros of KLP_* is about the state of the transition.
> Rename macros of KLP_* to KLP_TRANSITION_* to fix the confusing
> description of klp transition state.
>
> Signed-off-by: Wardenjohn
Looks good t
On Mon, 2024-05-06 at 12:32 -0400, Liam R. Howlett wrote:
>
> I like this patch.
Thanks for taking a look.
>
> I think the context of current->mm is implied. IOW, could we call it
> get_unmapped_area() instead? There are other functions today that use
> current->mm that don't start with curren
On Mon, 2024-05-06 at 09:18 -0700, Christoph Hellwig wrote:
> > On Mon, May 06, 2024 at 09:07:47AM -0700, Rick Edgecombe wrote:
> > > > if (flags & MAP_FIXED) {
> > > > /* Ok, don't mess with it. */
> > > > - return mm_get_unmapped_area(current->mm, NULL,
> > >
On Thu, 18 Apr 2024 09:44:19 +0300, Dmitry Baryshkov wrote:
> Enable the FastRPC and glink-edge nodes on MSM8996 platform. Tested on
> APQ8096 Dragonboard820c.
>
>
Applied, thanks!
[1/3] dt-bindings: remoteproc: qcom,msm8996-mss-pil: allow glink-edge on msm8996
commit: a0acdef561d1699b0
On Thu, 25 Apr 2024 21:14:29 +0200, Luca Weiss wrote:
> The mboxes property has been supported in those bindings since a while
> and was always meant to the replace qcom,ipc properties, so let's mark
> qcom,ipc as deprecated - and update the examples to use mboxes.
>
> Related:
> https://lore.ke
On Sun, 07 Apr 2024 11:58:29 +0200, Luca Weiss wrote:
> The original motivation is that a bunch of other schemas fail to
> validate qcom,halt-regs, for example like in the following examples:
>
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtb: remoteproc@408:
> qcom,halt-regs:0: [20] is too short
Hi,
Here is the 10th version of the series to re-implement the fprobe on
function-graph tracer. The previous version is;
https://lore.kernel.org/all/171318533841.254850.15841395205784342850.stgit@devnote2/
This version is ported on the latest kernel (v6.9-rc6 + probes/for-next)
and fixed some bu
From: Masami Hiramatsu (Google)
To clarify what will be expected on ftrace_regs, add a comment to the
architecture independent definition of the ftrace_regs.
Signed-off-by: Masami Hiramatsu (Google)
Acked-by: Mark Rutland
---
Changes in v8:
- Update that the saved registers depends on the c
From: Masami Hiramatsu (Google)
Add ftrace_regs definition for x86_64 in the ftrace header to
clarify what register will be accessible from ftrace_regs.
Signed-off-by: Masami Hiramatsu (Google)
---
Changes in v3:
- Add rip to be saved.
Changes in v2:
- Newly added.
---
arch/x86/include/a
From: Masami Hiramatsu (Google)
Rename ftrace_regs_return_value to ftrace_regs_get_return_value as same as
other ftrace_regs_get/set_* APIs.
Signed-off-by: Masami Hiramatsu (Google)
Acked-by: Mark Rutland
---
Changes in v6:
- Moved to top of the series.
Changes in v3:
- Newly added.
---
From: Steven Rostedt (VMware)
Instead of using "ALIGN()", use BUILD_BUG_ON() as the structures should
always be divisible by sizeof(long).
Link:
http://lkml.kernel.org/r/2019052444.gi2...@hirez.programming.kicks-ass.net
Suggested-by: Peter Zijlstra
Signed-off-by: Steven Rostedt (VMware)
From: Steven Rostedt (VMware)
Add an array structure that will eventually allow the function graph tracer
to have up to 16 simultaneous callbacks attached. It's an array of 16
fgraph_ops pointers, that is assigned when one is registered. On entry of a
function the entry of the first item in the a
From: Steven Rostedt (VMware)
The function pointers ftrace_graph_entry and ftrace_graph_return are no
longer called via the function_graph tracer. Instead, an array structure is
now used that will allow for multiple users of the function_graph
infrastructure. The variables are still used by the a
From: Steven Rostedt (VMware)
Pass the fgraph_ops structure to the function graph callbacks. This will
allow callbacks to add a descriptor to a fgraph_ops private field that wil
be added in the future and use it for the callbacks. This will be useful
when more than one callback can be registered
From: Steven Rostedt (VMware)
Now that function graph tracing can handle more than one user, allow it to
be enabled in the ftrace instances. Note, the filtering of the functions is
still joined by the top level set_ftrace_filter and friends, as well as the
graph and nograph files.
Signed-off-by:
From: Steven Rostedt (VMware)
Some of the flags for ftrace_startup() may be exposed even when
CONFIG_DYNAMIC_FTRACE is not configured in. This is fine as the difference
between dynamic ftrace and static ftrace is done within the internals of
ftrace itself. No need to have use cases fail to compil
From: Steven Rostedt (VMware)
Allow for instances to have their own ftrace_ops part of the fgraph_ops
that makes the funtion_graph tracer filter on the set_ftrace_filter file
of the instance and not the top instance.
Note that this also requires to update ftrace_graph_func() to call new
function
From: Masami Hiramatsu (Google)
Since the fgraph_array index is used for the bitmap on the shadow
stack, it may leave some entries after a function_graph instance is
removed. Thus if another instance reuses the fgraph_array index soon
after releasing it, the fgraph may confuse to call the newer c
From: Steven Rostedt (VMware)
Add a "task variables" array on the tasks shadow ret_stack that is the
size of longs for each possible registered fgraph_ops. That's a total
of 16, taking up 8 * 16 = 128 bytes (out of a page size 4k).
This will allow for fgraph_ops to do specific features on a per
From: Steven Rostedt (VMware)
Allow for multiple users to attach to function graph tracer at the same
time. Only 16 simultaneous users can attach to the tracer. This is because
there's an array that stores the pointers to the attached fgraph_ops. When
a function being traced is entered, each of t
From: Steven Rostedt (VMware)
The use of the task->trace_recursion for the logic used for the
set_graph_funnction was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use that
instead.
Signed-off-by: Steven Rostedt (VMware)
Si
From: Steven Rostedt (VMware)
The use of the task->trace_recursion for the logic used for the function
graph depth was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use that
instead.
Signed-off-by: Steven Rostedt (VMware)
S
From: Steven Rostedt (VMware)
Added functions that can be called by a fgraph_ops entryfunc and retfunc to
store state between the entry of the function being traced to the exit of
the same function. The fgraph_ops entryfunc() may call
fgraph_reserve_data() to store up to 32 words onto the task's
From: Steven Rostedt (VMware)
In order to make it possible to have multiple callbacks registered with the
function_graph tracer, the retstack needs to be converted from an array of
ftrace_ret_stack structures to an array of longs. This will allow to store
the list of callbacks on the stack for th
From: Steven Rostedt (VMware)
Add boot up selftest that passes variables from a function entry to a
function exit, and make sure that they do get passed around.
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Masami Hiramatsu (Google)
---
Changes in v2:
- Add reserved size test.
- U
From: Masami Hiramatsu (Google)
Add a selftest for multiple function graph tracer with storage on a same
function. In this case, the shadow stack entry will be shared among those
fgraph with different data storage. So this will ensure the fgraph will
not mixed those storage data.
Signed-off-by:
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 address) via this ftrace_regs.
Signed-off-by: Masami Hiramatsu (Google)
---
Changes in
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 is also replaced by
CONFIG_HAVE_FUNCTION_GRAPH_FREGS.
Signed-off-by: Masami Hiramatsu
From: Masami Hiramatsu (Google)
Pass ftrace_regs to the fgraph_ops::retfunc(). If ftrace_regs is not
available, it passes a NULL instead. User callback function can access
some registers (including return address) via this ftrace_regs.
Signed-off-by: Masami Hiramatsu (Google)
---
Changes in v8
From: Masami Hiramatsu (Google)
This allows fprobes to be available with CONFIG_DYNAMIC_FTRACE_WITH_ARGS
instead of CONFIG_DYNAMIC_FTRACE_WITH_REGS, then we can enable fprobe
on arm64.
Signed-off-by: Masami Hiramatsu (Google)
Acked-by: Florent Revest
---
Changes in v6:
- Keep using SAVE_REG
From: Masami Hiramatsu (Google)
Change the fprobe exit handler to use ftrace_regs structure instead of
pt_regs. This also introduce HAVE_PT_REGS_TO_FTRACE_REGS_CAST which means
the ftrace_regs's memory layout is equal to the pt_regs so that those are
able to cast. Fprobe introduces a new dependen
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 replacing the pt_regs with ftrace_regs in fprobes (which is
used by kprobe_multi eBPF event)
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_mode(regs) == false' and can be
used for stack tracing.
Signed-off-by: Masami Hiramat
From: Masami Hiramatsu (Google)
Allow fprobe events to be enabled with CONFIG_DYNAMIC_FTRACE_WITH_ARGS.
With this change, fprobe events mostly use ftrace_regs instead of pt_regs.
Note that if the arch doesn't enable HAVE_PT_REGS_COMPAT_FTRACE_REGS,
fprobe events will not be able to be used from p
From: Masami Hiramatsu (Google)
Enable kprobe_multi feature if CONFIG_FPROBE is enabled. The pt_regs is
converted from ftrace_regs by ftrace_partial_regs(), thus some registers
may always returns 0. But it should be enough for function entry (access
arguments) and exit (access return value).
Sig
From: Masami Hiramatsu (Google)
Add CONFIG_HAVE_FTRACE_GRAPH_FUNC kconfig in addition to ftrace_graph_func
macro check. This is for the other feature (e.g. FPROBE) which requires to
access ftrace_regs from fgraph_ops::entryfunc() can avoid compiling if
the fgraph can not pass the valid ftrace_reg
From: Masami Hiramatsu (Google)
Rewrite fprobe implementation on function-graph tracer.
Major API changes are:
- 'nr_maxactive' field is deprecated.
- This depends on CONFIG_DYNAMIC_FTRACE_WITH_ARGS or
!CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS, and
CONFIG_HAVE_FUNCTION_GRAPH_FREGS. So cur
From: Masami Hiramatsu (Google)
Remove depercated fprobe::nr_maxactive. This involves fprobe events to
rejects the maxactive number.
Signed-off-by: Masami Hiramatsu (Google)
---
Changes in v2:
- Newly added.
---
include/linux/fprobe.h |2 --
kernel/trace/trace_fprobe.c | 44 +
From: Masami Hiramatsu (Google)
Since the fprobe event does not support maxactive anymore, stop
testing the maxactive syntax error checking.
Signed-off-by: Masami Hiramatsu (Google)
---
.../ftrace/test.d/dynevent/fprobe_syntax_errors.tc |4 +---
1 file changed, 1 insertion(+), 3 deletions(
From: Masami Hiramatsu (Google)
This test case repeats define and undefine the fprobe dynamic event to
ensure that the fprobe does not cause any issue with such operations.
Signed-off-by: Masami Hiramatsu (Google)
---
.../test.d/dynevent/add_remove_fprobe_repeat.tc| 19 ++
From: Steven Rostedt (VMware)
The use of the task->trace_recursion for the logic used for the function
graph no-trace was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use
that instead.
Signed-off-by: Steven Rostedt (VMware)
From: Masami Hiramatsu (Google)
Update fprobe documentation for the new fprobe on function-graph
tracer. This includes some bahvior changes and pt_regs to
ftrace_regs interface change.
Signed-off-by: Masami Hiramatsu (Google)
---
Changes in v2:
- Update @fregs parameter explanation.
---
Doc
From: Masami Hiramatsu (Google)
Skip recording calltime and rettime if the fgraph_ops does not need it.
This is a kind of performance optimization for fprobe. Since the fprobe
user does not use these entries, recording timestamp in fgraph is just
a overhead (e.g. eBPF, ftrace). So introduce the s
v4.19.312-rt134-rc3 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c2c7e0fb6685..6067da4c8c99 100644
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.312-rt134-rc3.
Please scream at me if I messed something up. Please test the patches
too.
The -rc release is also available on kernel.org
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
on the v4.19-rt-nex
* Edgecombe, Rick P [240507 09:51]:
> On Mon, 2024-05-06 at 12:32 -0400, Liam R. Howlett wrote:
> >
> > I like this patch.
>
> Thanks for taking a look.
>
> >
> > I think the context of current->mm is implied. IOW, could we call it
> > get_unmapped_area() instead? There are other functions to
On Tue, May 7, 2024 at 3:54 AM Jiri Olsa wrote:
>
> Adding test to verify that when called from outside of the
> trampoline provided by kernel, the uretprobe syscall will cause
> calling process to receive SIGILL signal and the attached bpf
> program is not executed.
>
> Reviewed-by: Masami Hirama
On Tue, 2024-05-07 at 12:53 +0200, Jiri Olsa wrote:
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index 81e6ee95784d..ae6c3458a675 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -406,6 +406,11 @@ SYSCALL_DEFINE0(uretprobe)
> * tramp
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related
On Wed, May 1, 2024 at 7:06 PM Masami Hiramatsu wrote:
>
> On Tue, 30 Apr 2024 09:29:40 -0700
> Andrii Nakryiko wrote:
>
> > On Tue, Apr 30, 2024 at 6:32 AM Masami Hiramatsu
> > wrote:
> > >
> > > On Mon, 29 Apr 2024 13:25:04 -0700
> > > Andrii Nakryiko wrote:
> > >
> > > > On Mon, Apr 29, 202
On Sun, May 5, 2024 at 9:13 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:a9e7715ce8b3 libbpf: Avoid casts from pointers to enums in..
> git tree: bpf-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=153c1dc498
> kernel config:
On Mon May 6, 2024 at 7:07 PM EEST, Rick Edgecombe wrote:
> Recently the get_unmapped_area() pointer on mm_struct was removed in
> favor of direct callable function that can determines which of two
> handlers to call based on an mm flag. This function,
> mm_get_unmapped_area(), checks the flag of t
On Sun, 5 May 2024 19:06:17 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Move the logic related to the memory allocation and freeing into
> module_memory_alloc() and module_memory_free().
>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
Thanks,
> Signed-off-by:
On Sun, 5 May 2024 19:06:19 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Several architectures override module_alloc() only to define address
> range for code allocations different than VMALLOC address space.
>
> Provide a generic implementation in execmem that uses the parame
On Tue, 30 Apr 2024 12:13:51 +0100
Vincent Donnefort wrote:
> +#ifdef CONFIG_MMU
> +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> + struct vm_area_struct *vma)
> +{
> + unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
> + unsign
On Sat, May 4, 2024 at 2:10 AM Joseph Salisbury
wrote:
>
> Hi Feng,
>
> During testing, a kernel bug was identified with the suspend/resume
> functionality on instances running in a public cloud [0]. This bug is a
> regression introduced in v6.8-rc1. After a kernel bisect, the following
> commit
On Tue, May 7, 2024 at 11:06 AM maobibo wrote:
>
>
>
> On 2024/5/7 上午10:05, Huacai Chen wrote:
> > On Tue, May 7, 2024 at 9:40 AM maobibo wrote:
> >>
> >>
> >>
> >> On 2024/5/6 下午10:17, Huacai Chen wrote:
> >>> On Mon, May 6, 2024 at 6:05 PM maobibo wrote:
>
>
>
> On 2024/5/6
On Tue, May 07, 2024 at 01:01:11PM +0800, zhangwar...@gmail.com wrote:
> From: Wardenjohn
>
> The original macros of KLP_* is about the state of the transition.
> Rename macros of KLP_* to KLP_TRANSITION_* to fix the confusing
> description of klp transition state.
>
> Signed-off-by: Wardenjohn
On 2024/5/8 下午1:00, Huacai Chen wrote:
On Tue, May 7, 2024 at 11:06 AM maobibo wrote:
On 2024/5/7 上午10:05, Huacai Chen wrote:
On Tue, May 7, 2024 at 9:40 AM maobibo wrote:
On 2024/5/6 下午10:17, Huacai Chen wrote:
On Mon, May 6, 2024 at 6:05 PM maobibo wrote:
On 2024/5/6 下午5:40,
73 matches
Mail list logo
