On Tue, 22 Jul 2025 at 06:49, Kees Cook wrote:
>
> On Mon, Jul 21, 2025 at 01:14:36PM -0700, Kees Cook wrote:
> > On Mon, Jul 21, 2025 at 01:47:55PM +0100, Will Deacon wrote:
> > > On Sun, Jul 20, 2025 at 04:10:01PM +1000, Ard Biesheuvel wrote:
> > > > On Sat, 19 Jul 2025 at 08:51, Kees Cook wrot
On Sun, Jul 20, 2025 at 8:16 PM wrote:
>
> From: Fan Yu
>
> Background
> ==
> When TCP retransmits a packet due to missing ACKs, the
> retransmission may fail for various reasons (e.g., packets
> stuck in driver queues, receiver zero windows, or routing issues).
>
> The original tcp_retra
> > Thanks for checking! I just wanted to ensure the v7 patch wasn’t missed —
> > it’s identical to the original.
>
> You can check the patch status in patchwork, and actually this v7
> marked the previous v7 as Superseded, so you didn't need to resend :)
>
> https://patchwork.kernel.org/project
On Mon, Jul 21, 2025 at 6:48 PM wrote:
>
> > On Mon, 21 Jul 2025 11:16:07 +0800 (CST) fan@zte.com.cn wrote:
>
> > > Subject: [PATCH net-next v7 RESEND] tcp: trace retransmit failures in
> > > tcp_retransmit_skb
>
> >
>
> > Why did you resend this??
>
>
> Hi Jakub,
>
>
> Thanks for checking! I
在 2025/7/21 18:18, Ilpo Järvinen 写道:
On Fri, 18 Jul 2025, Shuai Xue wrote:
在 2025/7/18 11:46, Matthew W Carlis 写道:
On Thu, Jul 17, 2025 Bjorn Helgaas wrote
So I think your idea of adding current link speed/width to the "Link
Up" event is still on the table, and that does sound useful to me.
> On Mon, 21 Jul 2025 11:16:07 +0800 (CST) fan@zte.com.cn wrote:
> > Subject: [PATCH net-next v7 RESEND] tcp: trace retransmit failures in
> > tcp_retransmit_skb
>
> Why did you resend this??
Hi Jakub,
Thanks for checking! I just wanted to ensure the v7 patch wasn’t missed — it’s
identical
On Thu, 26 Jun 2025 18:04:59 +0200
Nam Cao wrote:
> > The above three interact with each other. Without the barriers, the
> > tr->buffer_disabled = 0, can be set on one CPU, and the other CPU can think
> > the buffer is still enabled and do work that will end up doing nothing. Or
> > it can be se
On Mon, 21 Jul 2025 11:16:07 +0800 (CST) fan@zte.com.cn wrote:
> Subject: [PATCH net-next v7 RESEND] tcp: trace retransmit failures in
> tcp_retransmit_skb
Why did you resend this??
On Fri, 2025-07-18 at 16:25 +0100, Leo Yan wrote:
[...]
> +__bpf_kfunc int bpf_perf_event_aux_pause(void *p__map, u64 flags, u32 pause)
> +{
> + struct bpf_map *map = p__map;
> + struct bpf_array *array = container_of(map, struct bpf_array, map);
Verifier makes sure that p__map is a not
On Mon, 21 Jul 2025 13:19:07 -0400
Steven Rostedt wrote:
> On Sun, 20 Jul 2025 15:21:47 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> >
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > -#
On Thu, 26 Jun 2025 14:34:05 +0200
Tomas Glozar wrote:
> +For time-sensitive actions, it is recommended to run **rtla
> timerlat** with BPF
> +support and RT priority. Note that due to implementational
> limitations, actions
> +might be delayed up to one second after tra
On Fri, 2025-07-18 at 16:38 +0100, Leo Yan wrote:
[...]
> Just clarify one thing, I defined the kfunc in new patch:
>
> int bpf_perf_event_aux_pause(void *p__map, u64 flags, u32 pause)
>
> Unlike your suggestion, I defined the first parameter as "void
> *p__map" (I refers to bpf_arena_alloc_p
On Mon, 21 Jul 2025 16:58:43 -0400
Mathieu Desnoyers wrote:
> > Honestly, I'm not sure it needs to be an ELF file. Just a file that has an
> > sframe section in it.
>
> Indu told me on IRC that for GNU/Linux, SFrame will be an
> allocated,loaded section in elf files.
Yes it is, but is that a
On 2025-07-21 14:53, Steven Rostedt wrote:
On Mon, 21 Jul 2025 11:20:34 -0400
Mathieu Desnoyers wrote:
Hi!
I've written up an RFC for a new system call to handle sframe registration
for shared libraries. There has been interest to cover both sframe in
the short term, but also JIT use-cases in
On Mon, Jul 21, 2025 at 01:14:36PM -0700, Kees Cook wrote:
> On Mon, Jul 21, 2025 at 01:47:55PM +0100, Will Deacon wrote:
> > On Sun, Jul 20, 2025 at 04:10:01PM +1000, Ard Biesheuvel wrote:
> > > On Sat, 19 Jul 2025 at 08:51, Kees Cook wrote:
> > > > On Fri, Jul 18, 2025 at 11:36:32AM +0300, Mike
On Mon, Jul 21, 2025 at 01:47:55PM +0100, Will Deacon wrote:
> On Sun, Jul 20, 2025 at 04:10:01PM +1000, Ard Biesheuvel wrote:
> > On Sat, 19 Jul 2025 at 08:51, Kees Cook wrote:
> > > On Fri, Jul 18, 2025 at 11:36:32AM +0300, Mike Rapoport wrote:
> > > > On Thu, Jul 17, 2025 at 04:25:09PM -0700, K
On Mon, 21 Jul 2025 11:20:34 -0400
Mathieu Desnoyers wrote:
> Hi!
>
> I've written up an RFC for a new system call to handle sframe registration
> for shared libraries. There has been interest to cover both sframe in
> the short term, but also JIT use-cases in the long term, so I'm
> covering bo
From: Steven Rostedt
The subsystem event test enables all "sched" events and makes sure there's
at least 3 different events in the output. It used to cat the entire trace
file to | wc -l, but on slow machines, that could last a very long time.
To solve that, it was changed to just read the first
On Mon, 21 Jul 2025 09:54:22 +0800
Tengda Wu wrote:
> I noticed this patch hasn't been merged yet. Do you plan to merge it soon?
> If you're too busy, would you like me to help submit it instead?
Nah, I simply forgot about it. Let me go write up a patch and send it
out.
-- Steve
On Sun, 20 Jul 2025 15:22:16 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Allocate temporary string buffers for parsing eprobe-events
> from heap instead of stack.
>
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Steven Rostedt (Google)
-- Steve
On Sun, 20 Jul 2025 15:21:47 +0900
"Masami Hiramatsu (Google)" wrote:
>
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> -#include
> -#include
> #include
> -#include
> -#include
> -#include
> #include
>
On Mon, 2025-07-21 at 17:15 +0200, Nam Cao wrote:
> On Mon, Jul 21, 2025 at 10:23:22AM +0200, Gabriele Monaco wrote:
> > The tss monitor currently guarantees task switches can happen only
> > while
> > scheduling, whereas the sncid monitor enforces scheduling occurs
> > with
> > interrupt disabled.
On Mon, 2025-07-21 at 16:04 +0200, Nam Cao wrote:
> On Mon, Jul 21, 2025 at 03:20:44PM +0200, Gabriele Monaco wrote:
> > Mmh, I'm not understanding how, let's assume I create a custom
> > reactor
> > as a kernel module and I want to use it on existing models (built
> > in or
> > modules themselv
On Mon, 2025-07-21 at 17:01 +0200, Nam Cao wrote:
> On Mon, Jul 21, 2025 at 10:23:20AM +0200, Gabriele Monaco wrote:
> > DA monitor can be accessed from multiple cores simultaneously, this
> > is
> > likely, for instance when dealing with per-task monitors reacting
> > on
> > events that do not
Hi!
I've written up an RFC for a new system call to handle sframe registration
for shared libraries. There has been interest to cover both sframe in
the short term, but also JIT use-cases in the long term, so I'm
covering both here in this RFC to provide the full context. Implementation
wise we c
On Mon, 2025-07-21 at 16:38 +0200, Nam Cao wrote:
> On Mon, Jul 21, 2025 at 10:23:18AM +0200, Gabriele Monaco wrote:
> > The current behaviour of rvgen when running with the -a option is
> > to append the necessary lines at the end of the configuration for
> > Kconfig, Makefile and tracepoints.
> >
On Mon, Jul 21, 2025 at 10:23:22AM +0200, Gabriele Monaco wrote:
> The tss monitor currently guarantees task switches can happen only while
> scheduling, whereas the sncid monitor enforces scheduling occurs with
> interrupt disabled.
>
> Replace the monitors with a more comprehensive specification
On Mon, Jul 21, 2025 at 10:23:20AM +0200, Gabriele Monaco wrote:
> DA monitor can be accessed from multiple cores simultaneously, this is
> likely, for instance when dealing with per-task monitors reacting on
> events that do not always occur on the CPU where the task is running.
> This can cause r
On Mon, Jul 21, 2025 at 10:23:19AM +0200, Gabriele Monaco wrote:
> The dot2c.py script generates all states in a single line. This breaks the
> 100 column limit when the state machines are non-trivial.
>
> Change dot2c.py to generate the states in separate lines in case the
> generated line is goi
On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> The field 'reacting' in struct rv_monitor is set but never used.
> Delete it.
>
> Signed-off-by: Nam Cao
> ---
Yeah seems to be the case, thanks for spotting it.
Reviewed-by: Gabriele Monaco
> include/linux/rv.h | 1 -
> kernel/
On Mon, Jul 21, 2025 at 10:23:18AM +0200, Gabriele Monaco wrote:
> The current behaviour of rvgen when running with the -a option is to
> append the necessary lines at the end of the configuration for Kconfig,
> Makefile and tracepoints.
> This is not always the desired behaviour in case of nested
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an
issue:
WARNING: ODEBUG bug in delete_node
[ cut here ]
ODEBUG: activate active (active state 0) object: 888148ef4dd8 object type:
rcu_head hint: 0x0
WARNING: CPU: 1 PID: 6466 at lib
On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> Each struct rv_reactor has a unique struct rv_reactor_def associated
> with it. struct rv_reactor is statically allocated, while struct
> rv_reactor_def is dynamically allocated.
>
> This makes the code more complicated than it should be:
>
>
Hello Josh,
thank you very much for your valuable feedback!
On 18.07.2025 18:59, Josh Poimboeuf wrote:
> On Fri, Jul 18, 2025 at 10:28:32AM +0200, Jens Remus wrote:
>> On 17.07.2025 13:09, Jens Remus wrote:
>>> On 17.07.2025 01:01, Josh Poimboeuf wrote:
On Thu, Jul 10, 2025 at 06:35:13PM +02
On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> Each struct rv_monitor has a unique struct rv_monitor_def associated
> with
> it. struct rv_monitor is statically allocated, while struct
> rv_monitor_def
> is dynamically allocated.
>
> This makes the code more complicated than it should be:
>
On Mon, Jul 21, 2025 at 12:29:24PM +0200, Gabriele Monaco wrote:
> On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> > As suggested by the name, the nop reactor does not do anything. It is
> > the
> > default reactor when nothing else is selected.
> >
> > However, the monitors already null-check
On Mon, Jul 21, 2025 at 03:20:44PM +0200, Gabriele Monaco wrote:
> Mmh, I'm not understanding how, let's assume I create a custom reactor
> as a kernel module and I want to use it on existing models (built in or
> modules themselves), I'd do.
>
> insmod myreactor
> echo myreactor > mymodel/react
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> rv_reactor has a reference counter to ensure it is not removed while
> monitors are still using it.
>
> However, this is futile, as __exit functions are not expected to fail
> and
> will proceed normally despite rv_unregister_reactor() returning
在 2025/7/19 15:11, Lukas Wunner 写道:
On Sat, Jul 19, 2025 at 01:23:28PM +0800, Shuai Xue wrote:
<...>-120 [002] . 104.864051: pci_hp_event: :00:03.0
slot:30, event:PCI_HOTPLUG_CARD_PRESENT
<...>-120 [002] . 104.864081: pci_hp_event: :00:03.0
On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> rv_monitor_def::task_monitor is not used. Delete it.
>
> Signed-off-by: Nam Cao
Reviewed-by: Gabriele Monaco
Thanks,
Gabriele
> ---
> kernel/trace/rv/rv.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/kernel/trace/rv/rv.h b/kerne
On Sun, Jul 20, 2025 at 04:10:01PM +1000, Ard Biesheuvel wrote:
> On Sat, 19 Jul 2025 at 08:51, Kees Cook wrote:
> > On Fri, Jul 18, 2025 at 11:36:32AM +0300, Mike Rapoport wrote:
> > > On Thu, Jul 17, 2025 at 04:25:09PM -0700, Kees Cook wrote:
> > > > When KCOV is enabled all functions get instru
On 07/18, Jeremy Linton wrote:
>
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -121,7 +121,7 @@ struct xol_area {
>
> static void uprobe_warn(struct task_struct *t, const char *msg)
> {
> - pr_warn("uprobe: %s:%d failed to %s\n", current->comm, current->pid,
> msg);
>
On Fri, 2025-07-18 at 16:58 +0200, Nam Cao wrote:
> ltl2k generates all variable definition in both ltl_start() and
> ltl_possible_next_states(). However, these two functions may not use
> all
> the variables, causing "unused variable" compiler warning.
>
> Change the script to only generate used
On Mon, 2025-07-21 at 11:47 +0200, Nam Cao wrote:
> As suggested by the name, the nop reactor does not do anything. It is
> the
> default reactor when nothing else is selected.
>
> However, the monitors already null-check the reactor function
> pointers.
> Thus, instead of a nop reactor, just set
On Fri, 18 Jul 2025, Shuai Xue wrote:
> 在 2025/7/18 11:46, Matthew W Carlis 写道:
> > On Thu, Jul 17, 2025 Bjorn Helgaas wrote
> > > So I think your idea of adding current link speed/width to the "Link
> > > Up" event is still on the table, and that does sound useful to me.
> >
> > We're already rea
As suggested by the name, the nop reactor does not do anything. It is the
default reactor when nothing else is selected.
However, the monitors already null-check the reactor function pointers.
Thus, instead of a nop reactor, just set the react function pointer to
NULL. The nop reactor can then be
The field 'reacting' in struct rv_monitor is set but never used. Delete it.
Signed-off-by: Nam Cao
---
include/linux/rv.h| 1 -
kernel/trace/rv/rv_reactors.c | 14 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/include/linux/rv.h b/include/linux/rv.h
i
rv_reactor has a reference counter to ensure it is not removed while
monitors are still using it.
However, this is futile, as __exit functions are not expected to fail and
will proceed normally despite rv_unregister_reactor() returning an error.
At the moment, reactors do not support being built
Each struct rv_monitor has a unique struct rv_monitor_def associated with
it. struct rv_monitor is statically allocated, while struct rv_monitor_def
is dynamically allocated.
This makes the code more complicated than it should be:
- Lookup is required to get the associated rv_monitor_def from r
Each struct rv_reactor has a unique struct rv_reactor_def associated with
it. struct rv_reactor is statically allocated, while struct rv_reactor_def
is dynamically allocated.
This makes the code more complicated than it should be:
- Lookup is required to get the associated rv_reactor_def from r
rv_monitor_def::task_monitor is not used. Delete it.
Signed-off-by: Nam Cao
---
kernel/trace/rv/rv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/rv/rv.h b/kernel/trace/rv/rv.h
index 98fca0a1adbc..873364094402 100644
--- a/kernel/trace/rv/rv.h
+++ b/kernel/trace/rv/rv.h
@@ -41
Hi,
This series removes some redundant code and simply RV.
Nam Cao (6):
rv: Remove unused field in struct rv_monitor_def
rv: Merge struct rv_monitor_def into struct rv_monitor
rv: Merge struct rv_reactor_def into struct rv_reactor
rv: Remove rv_reactor's reference counter
rv: Remove the
Steven or other tracing people, can you check below the
discussion/question on preferred placement of the tracing
related code.
On Thu, 17 Jul 2025, Shuai Xue wrote:
> 在 2025/7/17 06:25, Bjorn Helgaas 写道:
> > [+cc Ilpo, Jonathan (should have been included since the patch has his
> > Reviewed-by)
Add a per-cpu monitor as part of the sched model:
* opid: operations with preemption and irq disabled
Monitor to ensure wakeup and need_resched occur with irq and
preemption disabled or in irq handlers.
Signed-off-by: Gabriele Monaco
---
Documentation/trace/rv/monitor_sched.rst | 55 +
Add 2 per-task monitors as part of the sched model:
* nrp: need-resched preempts
Monitor to ensure preemption requires need resched.
* sssw: set state sleep and wakeup
Monitor to ensure sched_set_state to sleepable leads to sleeping and
sleeping tasks require wakeup.
Cc: Ingo Molnar
The tss monitor currently guarantees task switches can happen only while
scheduling, whereas the sncid monitor enforces scheduling occurs with
interrupt disabled.
Replace the monitors with a more comprehensive specification which
implies both but also ensures that:
* each scheduler call disable in
Add the following tracepoint:
* sched_set_need_resched(tsk, cpu, tif)
Called when a task is set the need resched [lazy] flag
Remove the unused ip parameter from sched_entry and sched_exit and alter
sched_entry to have a value of preempt consistent with the one used in
sched_switch.
Also adapt
DA monitor can be accessed from multiple cores simultaneously, this is
likely, for instance when dealing with per-task monitors reacting on
events that do not always occur on the CPU where the task is running.
This can cause race conditions where two events change the next state
and we see inconsis
The dot2c.py script generates all states in a single line. This breaks the
100 column limit when the state machines are non-trivial.
Change dot2c.py to generate the states in separate lines in case the
generated line is going to be too long.
Also adapt existing monitors with line length over the
The current behaviour of rvgen when running with the -a option is to
append the necessary lines at the end of the configuration for Kconfig,
Makefile and tracepoints.
This is not always the desired behaviour in case of nested monitors:
while tracepoints are not affected by nesting and the Makefile'
RV monitors relying on the preemptirqs tracepoints are set as dependent
on PREEMPT_TRACER and IRQSOFF_TRACER. In fact, those configurations do
enable the tracepoints but are not the minimal configurations enabling
them, which are TRACE_PREEMPT_TOGGLE and TRACE_IRQFLAGS (not selectable
manually).
S
Using DA monitors tracepoints with KASAN enabled triggers the following
warning:
BUG: KASAN: global-out-of-bounds in
do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0
Read of size 32 at addr aada8980 by task ...
Call Trace:
[...]
do_trace_event_raw_event_event_da_monitor+0xd6/
Monitors generated with dot2k have their registration function (the one
called during monitor initialisation) return always 0, even if the
registration failed on RV side.
This can hide potential errors.
Return the value returned by the RV register function.
Reviewed-by: Nam Cao
Signed-off-by: Ga
RV event tracepoints print a line with the format:
"event_xyz: S0 x event -> S1 "
"event_xyz: S1 x event -> S0 (final)"
While printing an event leading to a non-final state, the line
has a trailing white space (visible above before the closing ").
Adapt the format string not to print the
The RV da_monitor API allows to start monitors in two ways:
da_handle_start_event_NAME and da_handle_start_run_event_NAME.
The former is used when the event is followed by the initial state of
the module, so we ignore the event but we know the monitor is in the
initial state and can start monitorin
Currently the userspace RV tool starts a monitor and waits for the user
to press Ctrl-C (SIGINT) to terminate and stop the monitor.
This doesn't account for a scenario where a user starts RV in background
and simply kills it (SIGTERM unless the user specifies differently).
E.g.:
# rv mon wip &
#
Currently, the userspace RV tool skips trace events triggered by the RV
tool itself, this can be changed by passing the parameter -s, which sets
the variable config_my_pid to 0 (instead of the tool's PID).
This has the side effect of skipping events generated by idle (PID 0).
Set config_my_pid to
Hi Linus,
On 7/18/25 12:05 AM, Linus Torvalds wrote:
On Wed, 16 Jul 2025 at 13:47, Andrii Nakryiko wrote:
But given how frequently task->comm is referenced (pretty much any
profiler or tracer will capture this), it's just the widespread nature
of accessing task->comm in BPF programs/scripts th
69 matches
Mail list logo
