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 IRQ
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
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 examp
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 | 7
> -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;
> jonathan.le
> -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; maciej.fijalkow...
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;
> > bj.
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 lea
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 all
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 re
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 Parr
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() patchi
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 exec
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
> > omit
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 termin
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 b
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 8
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 s
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)"
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 e
> 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)
> r
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
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
> > > dri
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
repor
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. T
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 T
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 even
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: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 hea
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 some
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 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 h
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 u
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 de
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()), th
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 4
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
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 e
> 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 th
39 matches
Mail list logo
