On Sat, 02 Mar 2024 06:02:22 +0900,
Geert Uytterhoeven wrote:
>
> arch/sh/boot/compressed/cache.c:2:5: warning: no previous prototype for
> ‘cache_control’ [-Wmissing-prototypes]
> arch/sh/boot/compressed/misc.c:115:6: warning: no previous prototype for
> ‘ftrace_stub’ [-Wmissing-prototypes]
>
> On 05-Mar-2024, at 4:13 AM, Steven Rostedt wrote:
>
> From: "Steven Rostedt (Google)"
>
> This reverts 60be76eeabb3d ("tracing: Add size check when printing
> trace_marker output"). The only reason the precision check was added
> was because of a bug that miscalculated the write size of
From: "Steven Rostedt (Google)"
Limit the max print event of trace_marker to just 4K string size. This must
also be less than the amount that can be held by a trace_seq along with
the text that is before the output (like the task name, PID, CPU, state,
etc). As trace_seq is made to handle large
On Mon, 4 Mar 2024 21:48:44 -0500
Mathieu Desnoyers wrote:
> On 2024-03-04 21:37, Steven Rostedt wrote:
> > On Mon, 4 Mar 2024 21:35:38 -0500
> > Steven Rostedt wrote:
> >
> >>> And it's not for debugging, it's for validation of assumptions
> >>> made about an upper bound limit defined for a
It is useful to expose skb addr and sock addr to user in tracepoint
tcp_probe, so that we can get more information while monitoring
receiving of tcp data, by ebpf or other ways.
For example, we need to identify a packet by seq and end_seq when
calculate transmit latency between layer 2 and layer
On Tue, Mar 5, 2024 at 1:54 AM Björn Töpel wrote:
>
> Conor Dooley writes:
>
> > On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
> >> For now, we use stop_machine() to patch the text and when we use IPIs for
> >> remote icache flushes (which is emitted in patch_text_nosync()),
On 2024-03-04 21:37, Steven Rostedt wrote:
On Mon, 4 Mar 2024 21:35:38 -0500
Steven Rostedt wrote:
And it's not for debugging, it's for validation of assumptions
made about an upper bound limit defined for a compile-time
check, so as the code evolves issues are caught early.
validating is
On Mon, 4 Mar 2024 21:35:38 -0500
Steven Rostedt wrote:
> > And it's not for debugging, it's for validation of assumptions
> > made about an upper bound limit defined for a compile-time
> > check, so as the code evolves issues are caught early.
>
> validating is debugging.
Did Linus put you
On Mon, 4 Mar 2024 21:18:13 -0500
Mathieu Desnoyers wrote:
> On 2024-03-04 20:59, Steven Rostedt wrote:
> > On Mon, 4 Mar 2024 20:42:39 -0500
> > Mathieu Desnoyers wrote:
> >
> >> #define TRACE_OUTPUT_META_DATA_MAX_LEN 80
> >>
> >> and a runtime check in the code generating this
On 2024-03-04 20:59, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:42:39 -0500
Mathieu Desnoyers wrote:
#define TRACE_OUTPUT_META_DATA_MAX_LEN 80
and a runtime check in the code generating this header.
This would avoid adding an unchecked upper limit.
That would be a lot of complex
On Mon, 4 Mar 2024 20:42:39 -0500
Mathieu Desnoyers wrote:
> #define TRACE_OUTPUT_META_DATA_MAX_LEN80
>
> and a runtime check in the code generating this header.
>
> This would avoid adding an unchecked upper limit.
That would be a lot of complex code that is for debugging
On Mon, 4 Mar 2024 20:36:28 -0500
Mathieu Desnoyers wrote:
> > <...>-999 [001] . 2296.140373: tracing_mark_write:
> > hello
> > ^^^
> > This is the meta data that is added to trace_seq
>
> If this
On 2024-03-04 20:41, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:35:16 -0500
Steven Rostedt wrote:
BUILD_BUG_ON(TRACING_MARK_MAX_SIZE + sizeof(meta data stuff...) >
TRACE_SEQ_SIZE);
That's not the meta size I'm worried about. The sizeof(meta data) is the
raw event binary data, which is not
On Mon, 4 Mar 2024 20:35:16 -0500
Steven Rostedt wrote:
> > BUILD_BUG_ON(TRACING_MARK_MAX_SIZE + sizeof(meta data stuff...) >
> > TRACE_SEQ_SIZE);
>
> That's not the meta size I'm worried about. The sizeof(meta data) is the
> raw event binary data, which is not related to the size of the
On 2024-03-04 20:35, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:15:57 -0500
Mathieu Desnoyers wrote:
On 2024-03-04 19:27, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of the entire
On Mon, 4 Mar 2024 20:15:57 -0500
Mathieu Desnoyers wrote:
> On 2024-03-04 19:27, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > Since the size of trace_seq's buffer is the max an event can output, have
> > the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K.
On 2024-03-04 19:27, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K. That
will keep writes that has meta data written from being dropped (but
On Mon, Mar 04, 2024 at 09:28:45PM +0100, Karel Balej wrote:
> Dmitry,
>
> Dmitry Torokhov, 2024-03-03T12:39:46-08:00:
> > On Sun, Mar 03, 2024 at 11:04:25AM +0100, Karel Balej wrote:
> > > From: Karel Balej
> > >
> > > Marvell 88PM886 PMIC provides onkey among other things. Add client
> > >
On Mon, 4 Mar 2024 16:43:46 -0800
Randy Dunlap wrote:
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 8198bfc54b58..d68544aef65f 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -7320,6 +7320,17 @@ tracing_mark_write(struct file *filp, const char
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8198bfc54b58..d68544aef65f 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7320,6 +7320,17 @@ tracing_mark_write(struct file *filp, const char
> __user *ubuf,
> if ((ssize_t)cnt < 0)
>
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K. That
will keep writes that has meta data written from being dropped (but
reported), because the total output of the print
On Mon, 4 Mar 2024 18:55:00 -0500
Steven Rostedt wrote:
> On Mon, 4 Mar 2024 18:23:41 -0500
> Mathieu Desnoyers wrote:
>
> > It appears to currently be limited by
> >
> > #define TRACE_SEQ_BUFFER_SIZE (PAGE_SIZE * 2 - \
> > (sizeof(struct seq_buf) + sizeof(size_t) + sizeof(int)))
>
From: "Steven Rostedt (Google)"
The trace_seq buffer is used to print out entire events. It's typically
set to PAGE_SIZE * 2 as there's some events that can be quite large.
As a side effect, writes to trace_marker is limited by both the size of the
trace_seq buffer as well as the ring buffer's
On Mon, 4 Mar 2024 18:23:41 -0500
Mathieu Desnoyers wrote:
> It appears to currently be limited by
>
> #define TRACE_SEQ_BUFFER_SIZE (PAGE_SIZE * 2 - \
> (sizeof(struct seq_buf) + sizeof(size_t) + sizeof(int)))
>
> checked within tracing_mark_write().
Yeah, I can hard code this to
On 2024-03-04 17:43, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
This reverts 60be76eeabb3d ("tracing: Add size check when printing
trace_marker output"). The only reason the precision check was added
was because of a bug that miscalculated the write size of the string into
the ring
From: "Steven Rostedt (Google)"
This reverts 60be76eeabb3d ("tracing: Add size check when printing
trace_marker output"). The only reason the precision check was added
was because of a bug that miscalculated the write size of the string into
the ring buffer and it truncated it removing the
Dmitry,
Dmitry Torokhov, 2024-03-03T12:39:46-08:00:
> On Sun, Mar 03, 2024 at 11:04:25AM +0100, Karel Balej wrote:
> > From: Karel Balej
> >
> > Marvell 88PM886 PMIC provides onkey among other things. Add client
> > driver to handle it. The driver currently only provides a basic support
> >
Conor Dooley writes:
> On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
>> For now, we use stop_machine() to patch the text and when we use IPIs for
>> remote icache flushes (which is emitted in patch_text_nosync()), the system
>> hangs.
>>
>> So instead, make sure every CPU
On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
> For now, we use stop_machine() to patch the text and when we use IPIs for
> remote icache flushes (which is emitted in patch_text_nosync()), the system
> hangs.
>
> So instead, make sure every CPU executes the stop_machine()
On Thu, Feb 29, 2024 at 01:10:55PM +0100, Alexandre Ghiti wrote:
> This memory barrier is not needed and not documented so simply remove
> it.
This looks like it should be patch 2 in the series, not patch 1, as it
is cleanup rather than a fix that needs backporting.
>
> Suggested-by: Andrea
Good day Abdellatif,
On Fri, Mar 01, 2024 at 04:42:25PM +, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> introduce remoteproc support for Arm remote processors
>
> The supported remote processors are those that come with a reset
> control register and a reset status
On Fri, Mar 01, 2024 at 04:42:25PM +, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> introduce remoteproc support for Arm remote processors
>
> The supported remote processors are those that come with a reset
> control register and a reset status register. The driver
From: Jakub Kicinski
softnet_data->time_squeeze is sometimes used as a proxy for
host overload or indication of scheduling problems. In practice
this statistic is very noisy and has hard to grasp units -
e.g. is 10 squeezes a second to be expected, or high?
Delaying network (NAPI) processing
On Thu, 29 Feb 2024 at 13:52, wangyunjian wrote:
>
> > -Original Message-
> > From: Paolo Abeni [mailto:pab...@redhat.com]
> > Sent: Thursday, February 29, 2024 6:43 PM
> > To: wangyunjian ; m...@redhat.com;
> > willemdebruijn.ker...@gmail.com; jasow...@redhat.com; k...@kernel.org;
> >
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Friday, March 1, 2024 7:53 PM
> To: wangyunjian
> Cc: Paolo Abeni ; willemdebruijn.ker...@gmail.com;
> jasow...@redhat.com; k...@kernel.org; bj...@kernel.org;
> magnus.karls...@intel.com;
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, March 4, 2024 2:56 PM
> To: wangyunjian
> Cc: m...@redhat.com; willemdebruijn.ker...@gmail.com; k...@kernel.org;
> bj...@kernel.org; magnus.karls...@intel.com; maciej.fijalkow...@intel.com;
>
From: Jason Xing
Use the existing parameter and print the address of skbaddr
as other trace functions do.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
From: Jason Xing
Printing the addresses can help us identify the exact skb/sk
for those system in which it's not that easy to run BPF program.
As we can see, it already fetches those, then use it directly
and it will print like below:
...tcp_retransmit_skb: skbaddr=XXX skaddr=XXX
From: Jason Xing
When I reviewed other people's patch [1], I noticed that similar things
also happen in tcp_event_skb class and tcp_event_sk_skb class. They
don't print those two addrs of skb/sk which already exist.
In this patch, I just do as other trace functions do, like
On 2024/3/2 下午5:41, WANG Xuerui wrote:
On 3/2/24 16:47, Bibo Mao wrote:
Add documentation topic for using pv_virt when running as a guest
on KVM hypervisor.
Signed-off-by: Bibo Mao
---
Documentation/virt/kvm/index.rst | 1 +
.../virt/kvm/loongarch/hypercalls.rst |
On Mon, Mar 4, 2024 at 4:24 PM Eric Dumazet wrote:
>
> On Thu, Feb 29, 2024 at 6:10 PM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > Prio to this patch, the trace function doesn't print addresses
> > which might be forgotten. As we can see, it already fetches
> > those, use it directly and
Eric Dumazet 于2024年3月4日周一 16:13写道：
>
> On Mon, Mar 4, 2024 at 4:46 AM fuyuanli wrote:
> >
> > It is useful to expose skb addr and sock addr to user in tracepoint
> > tcp_probe, so that we can get more information while monitoring
> > receiving of tcp data, by ebpf or other ways.
> >
> > For
On Thu, Feb 29, 2024 at 6:10 PM Jason Xing wrote:
>
> From: Jason Xing
>
> Prio to this patch, the trace function doesn't print addresses
> which might be forgotten. As we can see, it already fetches
> those, use it directly and it will print like below:
>
> ...tcp_retransmit_skb: skbaddr=XXX
On Mon, Mar 4, 2024 at 8:01 AM Jason Xing wrote:
>
> On Fri, Mar 1, 2024 at 1:10 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > When I reviewed other people's patch [1], I noticed that similar thing
> > also happens in tcp_event_skb class and tcp_event_sk_skb class. They
> > don't print
On Mon, Mar 4, 2024 at 4:46 AM fuyuanli wrote:
>
> It is useful to expose skb addr and sock addr to user in tracepoint
> tcp_probe, so that we can get more information while monitoring
> receiving of tcp data, by ebpf or other ways.
>
> For example, we need to identify a packet by seq and end_seq
On 03/03/2024 11:04, Karel Balej wrote:
> From: Karel Balej
>
> +examples:
> + - |
> +#include
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pmic@30 {
> +compatible = "marvell,88pm886-a1";
> +reg = <0x30>;
> +interrupts = <0 4
46 matches
Mail list logo
