On Mon, Mar 25, 2024 at 11:43 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Using the macro for other tracepoints use to be more concise.
> No functional change.
>
> Jason Xing (3):
> trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
> trace: use TP_STORE_ADDRS() macro in
On Mon, Mar 25, 2024 at 7:17 PM Rick Edgecombe
wrote:
>
>
> diff --git a/mm/util.c b/mm/util.c
> index 669397235787..8619d353a1aa 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -469,17 +469,17 @@ void arch_pick_mmap_layout(struct mm_struct *mm, struct
> rlimit *rlim_stack)
>
> if
"Ho-Ren (Jack) Chuang" writes:
> On Fri, Mar 22, 2024 at 1:41 AM Huang, Ying wrote:
>>
>> "Ho-Ren (Jack) Chuang" writes:
>>
>> > The current implementation treats emulated memory devices, such as
>> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
>> >
On Tue, Mar 26, 2024 at 10:23 AM Jakub Kicinski wrote:
>
> On Tue, 26 Mar 2024 10:13:55 +0800 Jason Xing wrote:
> > Yesterday, I posted two series to do two kinds of things. They are not
> > the same. Maybe you get me wrong :S
>
> Ah, my bad, sorry about that. I see that they are different now.
On Mon, 25 Mar 2024 11:29:18 +0100 Balazs Scheidler wrote:
> +memset(__entry->saddr, 0, sizeof(struct sockaddr_in6));
> +memset(__entry->daddr, 0, sizeof(struct sockaddr_in6));
Indent with tabs please, checkpatch says:
ERROR: code indent should use tabs where
On Tue, 26 Mar 2024 10:13:55 +0800 Jason Xing wrote:
> Yesterday, I posted two series to do two kinds of things. They are not
> the same. Maybe you get me wrong :S
Ah, my bad, sorry about that. I see that they are different now.
One is v1 the other v2, both targeting tcp tracing... Easy to miss
The mm_struct contains a function pointer *get_unmapped_area(), which
is set to either arch_get_unmapped_area() or
arch_get_unmapped_area_topdown() during the initialization of the mm.
Since the function pointer only ever points to two functions that are named
the same across all arch's, a
On Tue, Mar 26, 2024 at 9:30 AM Jakub Kicinski wrote:
>
> On Mon, 25 Mar 2024 14:28:28 +0800 Jason Xing wrote:
> > Before this, we miss some cases where the TCP layer could send rst but
> > we cannot trace it. So I decided to complete it :)
> >
> > v2
> > 1. fix spelling mistakes
>
> Not only do
On Tue Mar 26, 2024 at 3:31 AM EET, Jarkko Sakkinen wrote:
> > > +#endif /* _LINUX_EXECMEM_H */
> > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > index 9d9095e81792..87fd8c14a938 100644
> > > --- a/kernel/kprobes.c
> > > +++ b/kernel/kprobes.c
> > > @@ -44,6 +44,7 @@
> > > #include
>
On Tue Mar 26, 2024 at 2:58 AM EET, Masami Hiramatsu (Google) wrote:
> On Mon, 25 Mar 2024 23:55:01 +0200
> Jarkko Sakkinen wrote:
>
> > Tracing with kprobes while running a monolithic kernel is currently
> > impossible because CONFIG_KPROBES depends on CONFIG_MODULES because it uses
> > the
On Mon, 25 Mar 2024 14:28:28 +0800 Jason Xing wrote:
> Before this, we miss some cases where the TCP layer could send rst but
> we cannot trace it. So I decided to complete it :)
>
> v2
> 1. fix spelling mistakes
Not only do you post it before we "officially" open net-next but
also ignoring the
Tacing with kprobes while running a monolithic kernel is currently
impossible due the kernel module allocator dependency.
Address the issue by implementing textmem API for RISC-V.
Link: https://www.sochub.fi # for power on testing new SoC's with a minimal
stack
Link:
Tracing with kprobes while running a monolithic kernel is currently
impossible because CONFIG_KPROBES depends on CONFIG_MODULES.
Introduce alloc_execmem() and free_execmem() for allocating executable
memory. If an arch implements these functions, it can mark this up with
the HAVE_ALLOC_EXECMEM
On Mon, 25 Mar 2024 23:55:01 +0200
Jarkko Sakkinen wrote:
> Tracing with kprobes while running a monolithic kernel is currently
> impossible because CONFIG_KPROBES depends on CONFIG_MODULES because it uses
> the kernel module allocator.
>
> Introduce alloc_textmem() and free_textmem() for
On Mon, 25 Mar 2024 11:38:48 +0900
Masami Hiramatsu (Google) wrote:
> On Fri, 22 Mar 2024 09:03:23 -0700
> Andrii Nakryiko wrote:
>
> > Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
> > control whether ftrace low-level code performs additional
> > rcu_is_watching()-based
On Mon Mar 25, 2024 at 10:37 PM EET, Jarkko Sakkinen wrote:
> - if (ret == -ENOENT && !trace_kprobe_module_exist(tk)) {
> +#ifdef CONFIG_MODULES
> + if (ret == -ENOENT && trace_kprobe_module_exist(tk))
> + ret = 0;
> +#endif /* CONFIG_MODULES */
For this we could have
#ifndef
Hi Wolfram,
> > @Andi: are you okay with this approach? It means you'd need to merge
> > -rc2 into your for-next branch. Or rebase if all fails.
>
> I think it's a good plan, I'll try to support you with it.
Do you feel more comfortable if I take the patches as soon as
they are reviewd?
So far
On Tue Mar 26, 2024 at 1:50 AM EET, Masami Hiramatsu (Google) wrote:
> On Tue, 26 Mar 2024 00:09:42 +0200
> "Jarkko Sakkinen" wrote:
>
> > On Mon Mar 25, 2024 at 11:55 PM EET, Jarkko Sakkinen wrote:
> > > +#ifdef CONFIG_MODULES
> > > if (register_module_notifier(_kprobe_module_nb))
> > >
On Tue, 26 Mar 2024 00:09:42 +0200
"Jarkko Sakkinen" wrote:
> On Mon Mar 25, 2024 at 11:55 PM EET, Jarkko Sakkinen wrote:
> > +#ifdef CONFIG_MODULES
> > if (register_module_notifier(_kprobe_module_nb))
> > return -EINVAL;
> > +#endif /* CONFIG_MODULES */
>
>
On Mon, Mar 25, 2024 at 10:27 AM Andrii Nakryiko
wrote:
>
> On Sun, Mar 24, 2024 at 5:07 PM Alexei Starovoitov
> wrote:
> >
> > Hi Andrii,
> >
> > syzbot found UAF in raw_tp cookie series in bpf-next.
> > Reverting the whole merge
> > 2e244a72cd48 ("Merge branch
On 3/25/2024 15:31, Borislav Petkov wrote:
> On Mon, Mar 25, 2024 at 03:12:14PM -0500, Naik, Avadhut wrote:
>> Can this patchset be merged in? Or would you prefer me sending out
>> another revision with Steven's "Reviewed-by:" tag?
>
> First of all, please do not top-post.
>
Apologies for
On Mon Mar 25, 2024 at 4:56 AM EET, Masami Hiramatsu (Google) wrote:
> Hi Jarkko,
>
> On Sun, 24 Mar 2024 01:29:08 +0200
> Jarkko Sakkinen wrote:
>
> > Tracing with kprobes while running a monolithic kernel is currently
> > impossible due the kernel module allocator dependency.
> >
> > Address
On Mon, Mar 25, 2024 at 08:28:27PM +0100, Konrad Dybcio wrote:
> On 24.03.2024 3:04 PM, Stanislav Jakubek wrote:
> > Add a device tree for the Motorola Moto G (2013) smartphone based
> > on the Qualcomm MSM8226 SoC.
> >
> > Initially supported features:
> > - Buttons (Volume Down/Up, Power)
> >
On Mon, Mar 25, 2024 at 12:12 PM Jonthan Haslam
wrote:
>
> Hi Ingo,
>
> > > This change has been tested against production workloads that exhibit
> > > significant contention on the spinlock and an almost order of magnitude
> > > reduction for mean uprobe execution time is observed (28 -> 3.5
>
On Fri, Mar 08, 2024 at 03:47:07PM +0100, Arnaud Pouliquen wrote:
> To prepare for the support of TEE remoteproc, create sub-functions
> that can be used in both cases, with and without TEE support.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/remoteproc/stm32_rproc.c | 84
On Mon, 25 Mar 2024 21:01:04 +0900 Honggyu Kim wrote:
> Hi SeongJae,
>
> On Fri, 22 Mar 2024 09:32:23 -0700 SeongJae Park wrote:
> > On Fri, 22 Mar 2024 18:02:23 +0900 Honggyu Kim wrote:
[...]
> > > > Honggyu joined DAMON Beer/Coffee/Tea Chat[1] yesterday, and we
> > > > discussed about
> >
On Wed Mar 6, 2024 at 10:05 PM EET, Calvin Owens wrote:
> Hello all,
>
> This patchset makes it possible to use bpftrace with kprobes on kernels
> built without loadable module support.
>
> On a Raspberry Pi 4b, this saves about 700KB of memory where BPF is
> needed but loadable module support is
On Tue Mar 26, 2024 at 12:09 AM EET, Jarkko Sakkinen wrote:
> On Mon Mar 25, 2024 at 11:55 PM EET, Jarkko Sakkinen wrote:
> > +#ifdef CONFIG_MODULES
> > if (register_module_notifier(_kprobe_module_nb))
> > return -EINVAL;
> > +#endif /* CONFIG_MODULES */
>
>
On Mon Mar 25, 2024 at 11:55 PM EET, Jarkko Sakkinen wrote:
> +#ifdef CONFIG_MODULES
> if (register_module_notifier(_kprobe_module_nb))
> return -EINVAL;
> +#endif /* CONFIG_MODULES */
register_module_notifier() does have "dummy" version but what
would I pass to it. It makes
s/textmem/execmem/ (also in long description)
will hold sending a new version as not a functional issue, will fix
after review.
BR, Jarkko
Tacing with kprobes while running a monolithic kernel is currently
impossible due the kernel module allocator dependency.
Address the issue by implementing textmem API for RISC-V.
Link: https://www.sochub.fi # for power on testing new SoC's with a minimal
stack
Link:
Tracing with kprobes while running a monolithic kernel is currently
impossible because CONFIG_KPROBES depends on CONFIG_MODULES because it uses
the kernel module allocator.
Introduce alloc_textmem() and free_textmem() for allocating executable
memory. If an arch implements these functions, it can
Tracing with kprobes while running a monolithic kernel is currently
impossible because CONFIG_KPROBES depends on CONFIG_MODULES because it uses
the kernel module allocator.
Introduce alloc_textmem() and free_textmem() for allocating executable
memory. If an arch implements these functions, it can
Tacing with kprobes while running a monolithic kernel is currently
impossible due the kernel module allocator dependency.
Address the issue by implementing textmem API for RISC-V.
Link: https://www.sochub.fi # for power on testing new SoC's with a minimal
stack
Link:
Tracing with kprobes while running a monolithic kernel is currently
impossible because CONFIG_KPROBES depends on CONFIG_MODULES because it uses
the kernel module allocator.
Introduce alloc_textmem() and free_textmem() for allocating executable
memory. If an arch implements these functions, it can
On Mon Mar 25, 2024 at 10:37 PM EET, Jarkko Sakkinen wrote:
> Tacing with kprobes while running a monolithic kernel is currently
> impossible due the kernel module allocator dependency.
>
> Address the issue by implementing textmem API for RISC-V.
>
> Link: https://www.sochub.fi # for power on
Tacing with kprobes while running a monolithic kernel is currently
impossible due the kernel module allocator dependency.
Address the issue by implementing textmem API for RISC-V.
Link: https://www.sochub.fi # for power on testing new SoC's with a minimal
stack
Link:
Hi SeongJae,
On Fri, 22 Mar 2024 09:32:23 -0700 SeongJae Park wrote:
> On Fri, 22 Mar 2024 18:02:23 +0900 Honggyu Kim wrote:
>
> > Hi SeongJae,
> >
> > On Tue, 27 Feb 2024 15:51:20 -0800 SeongJae Park wrote:
> > > On Mon, 26 Feb 2024 23:05:46 +0900 Honggyu Kim wrote:
> > >
> > > > There
On Mon, Mar 25, 2024 at 03:12:14PM -0500, Naik, Avadhut wrote:
> Can this patchset be merged in? Or would you prefer me sending out
> another revision with Steven's "Reviewed-by:" tag?
First of all, please do not top-post.
Then, you were on Cc on the previous thread. Please summarize from it
and
Hi Boris,
Can this patchset be merged in? Or would you prefer me sending out another
revision with Steven's "Reviewed-by:" tag?
On 2/8/2024 11:10, Steven Rostedt wrote:
> On Fri, 26 Jan 2024 01:57:58 -0600
> Avadhut Naik wrote:
>
>> This patchset updates the mce_record tracepoint so that the
Hi Mathieu,
> > > > > > > > This is an initial patchset for allowing to turn on and off the
> > > > > > > > remote processor.
> > > > > > > > The FW is already loaded before the Corstone-1000 SoC is
> > > > > > > > powered on and this
> > > > > > > > is done through the FPGA board bootloader in
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). This type should have been defined as
u32. Instead of making that change here, simply remove the header usage
and fix
On Fri, Mar 08, 2024 at 10:18:18AM +0800, Kassey Li wrote:
> The trace event "workqueue_activate_work" only print work struct.
> However, function is the region of interest in a full sequence of work.
> Current workqueue_activate_work trace event output:
>
> workqueue_activate_work: work
On 24.03.2024 3:04 PM, Stanislav Jakubek wrote:
> Add a device tree for the Motorola Moto G (2013) smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Initially supported features:
> - Buttons (Volume Down/Up, Power)
> - eMMC
> - Hall Effect Sensor
> - SimpleFB display
> - TMP108
On Mon Mar 25, 2024 at 9:11 PM EET, Jarkko Sakkinen wrote:
> On Mon Mar 25, 2024 at 8:37 PM EET, Jarkko Sakkinen wrote:
> > > You also should consider using IS_ENABLED(CONFIG_MODULE) in the code to
> > > avoid using #ifdefs.
>
> Hmm... I need make a couple of remarks but open for feedback ofc.
>
>
Hi Ingo,
> > This change has been tested against production workloads that exhibit
> > significant contention on the spinlock and an almost order of magnitude
> > reduction for mean uprobe execution time is observed (28 -> 3.5 microsecs).
>
> Have you considered/measured per-CPU RW semaphores?
On Mon Mar 25, 2024 at 8:37 PM EET, Jarkko Sakkinen wrote:
> > You also should consider using IS_ENABLED(CONFIG_MODULE) in the code to
> > avoid using #ifdefs.
Hmm... I need make a couple of remarks but open for feedback ofc.
First, trace_kprobe_module_exist depends on find_module()
Second,
Hi Masami,
> > This change has been tested against production workloads that exhibit
> > significant contention on the spinlock and an almost order of magnitude
> > reduction for mean uprobe execution time is observed (28 -> 3.5 microsecs).
>
> Looks good to me.
>
> Acked-by: Masami Hiramatsu
On Mon, Mar 25, 2024 at 06:12:38PM +0100, Marco Pinna wrote:
Commit 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") added
virtio_transport_deliver_tap_pkt() for handing packets to the
vsockmon device. However, in virtio_transport_send_pkt_work(),
the function is called before actually
On Fri, 22 Mar 2024 09:01:31 +0100, Luca Weiss wrote:
> This series adds support for Type-C Port Management on the Fairphone 4
> which enables USB role switching and orientation switching.
>
> This enables a user for example to plug in a USB stick or a USB keyboard
> to the Type-C port.
>
>
>
This is only used internal to the driver, move it out of the
public header and into the driver file. While we are here,
this is not used as a bitwise, so drop that and make it a
simple enum type.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 5 +
On Sun, Mar 24, 2024 at 5:07 PM Alexei Starovoitov
wrote:
>
> Hi Andrii,
>
> syzbot found UAF in raw_tp cookie series in bpf-next.
> Reverting the whole merge
> 2e244a72cd48 ("Merge branch 'bpf-raw-tracepoint-support-for-bpf-cookie'")
>
> fixes the issue.
>
> Pls take a look.
> See C reproducer
The mbox_controller struct is only needed in the probe function. Make
it a local variable instead of storing a copy in omap_mbox_device
to simplify that struct.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 21 -
1 file changed, 12 insertions(+), 9
The driver stores a list of omap_mbox structs so it can later use it to
lookup the mailbox names in of_xlate. This same information is already
available in the mbox_controller passed into of_xlate. Simply use that
data and remove the extra allocation and storage of the omap_mbox list.
It is much more clear to check if the hardware FIFO is full and return
EBUSY if true. This allows us to also remove one level of indention
from the core of this function. It also makes the similarities between
omap_mbox_chan_send_noirq() and omap_mbox_chan_send() more obvious.
Signed-off-by:
Hello all,
Core of this series is the last patch removing the message FIFO
from OMAP mailbox. This hurts our real-time performance. It was a
legacy leftover from before the common mailbox framework anyway.
The rest of the patches are cleanups found along the way.
Thanks,
Andrew
Andrew Davis
The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.
The whole FIFO idea itself looks to be a leftover from before the
unified mailbox framework. The
This function only checks if mbox_chan *chan is not NULL, but that cannot
be the case and if it was returning NULL which is not later checked
doesn't save us from this. The second check for chan->con_priv is
completely redundant as if it was NULL we would return NULL just the
same. Simply
These function are not used, remove these here.
While here, remove the leading _ from the driver internal functions that
do the same thing as the functions removed.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 --
Currently the driver loops through all mailbox child nodes twice, once
to read in data from each node, and again to make use of this data.
Instead read the data and make use of it in one pass. This removes
the need for several temporary data structures and reduces the
complexity of this main loop
The driver currently creates a new device class "mbox". Then for each
mailbox adds a device to that class. This class provides no file
operations provided for any userspace users of this device class.
It may have been extended to be functional in our vendor tree at
some point, but that is not the
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c
The mbox_kfifo_size can be changed at runtime, the sanity
check on it's value should be done when it is used, not
only once at init time.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
This function is not used, remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 36 --
include/linux/omap-mailbox.h | 6 --
2 files changed, 42 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c
Commit 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") added
virtio_transport_deliver_tap_pkt() for handing packets to the
vsockmon device. However, in virtio_transport_send_pkt_work(),
the function is called before actually sending the packet (i.e.
before placing it in the virtqueue with
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Use u32 unconditionally and remove
the now unneeded omap-mailbox.h include.
Signed-off-by: Andrew Davis
---
This header no longer used, remove this include.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 8f50ab80e56f4..bde04e3e6d966 100644
---
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Use u32 unconditionally and remove
the now unneeded omap-mailbox.h include.
Signed-off-by: Andrew Davis
---
On Sun, Mar 24, 2024 at 7:38 PM Masami Hiramatsu wrote:
>
> On Fri, 22 Mar 2024 09:03:23 -0700
> Andrii Nakryiko wrote:
>
> > Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
> > control whether ftrace low-level code performs additional
> > rcu_is_watching()-based validation
On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pouliquen wrote:
> The new TEE remoteproc device is used to manage remote firmware in a
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In
On Fri, Mar 08, 2024 at 03:47:05PM +0100, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this device offers a client
Device or driver? I thought I
This patch moves TP_STORE_ADDR_PORTS_SKB() to a common header and removes
the TCP specific implementation details.
Previously the macro assumed the skb passed as an argument is a
TCP packet, the implementation now uses an argument to the L4 header and
uses that to extract the source/destination
On Sun, 24 Mar 2024 15:03:59 +0100, Stanislav Jakubek wrote:
> Document the Motorola Moto G (2013), which is a smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Signed-off-by: Stanislav Jakubek
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
From: Yuxue Liu
In the vp_vdpa_set_status function, when setting the device status to
VIRTIO_CONFIG_S_DRIVER_OK, the vp_vdpa_request_irq function may fail.
In such cases, the device status should not be set to DRIVER_OK. Add
exception printing to remind the user.
Signed-off-by: Yuxue Liu
---
Hey,
>
> func_symbol:
> auipc t0, common_dispatch:high <=> j actual_func:
> jalr t0, common_dispatch:low(t0)
>
If you are patching in a jump, I don't see why you wouldn't jump over
ld+jalr? (no need for common dispatch)
Patching jalr with nop, and keeping auipc, addresses the issue with
having
Hello RT-list!
I'm pleased to announce the 5.10.213-rt105 stable release.
This release is an update to the new stable 5.10.213 version and no extra
changes have been performed.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
在 2024/3/25 下午7:35, Xuan Zhuo 写道:
On Mon, 25 Mar 2024 04:26:08 -0700, Breno Leitao wrote:
Hello Xuan,
On Mon, Mar 25, 2024 at 01:57:53PM +0800, Xuan Zhuo wrote:
On Fri, 22 Mar 2024 03:21:21 -0700, Breno Leitao wrote:
Hello Xuan,
On Fri, Mar 22, 2024 at 10:00:22AM +0800, Xuan Zhuo
>>
>> 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:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D
>> When an application
On 24/03/2024 15:03, Stanislav Jakubek wrote:
> Document the Motorola Moto G (2013), which is a smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Signed-off-by: Stanislav Jakubek
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
Acked-by: Krzysztof Kozlowski
Best regards,
On Mon, 25 Mar 2024 04:26:08 -0700, Breno Leitao wrote:
> Hello Xuan,
>
> On Mon, Mar 25, 2024 at 01:57:53PM +0800, Xuan Zhuo wrote:
> > On Fri, 22 Mar 2024 03:21:21 -0700, Breno Leitao wrote:
> > > Hello Xuan,
> > >
> > > On Fri, Mar 22, 2024 at 10:00:22AM +0800, Xuan Zhuo wrote:
> > > > On
From: Jason Xing
In addition to knowing the 4-tuple of the flow which generates RST,
the reason why it does so is very important because we have some
cases where the RST should be sent and have no clue which one
exactly.
Adding location of reset process can help us more, like what
Hello Xuan,
On Mon, Mar 25, 2024 at 01:57:53PM +0800, Xuan Zhuo wrote:
> On Fri, 22 Mar 2024 03:21:21 -0700, Breno Leitao wrote:
> > Hello Xuan,
> >
> > On Fri, Mar 22, 2024 at 10:00:22AM +0800, Xuan Zhuo wrote:
> > > On Thu, 21 Mar 2024 09:54:30 -0700, Breno Leitao
> > > wrote:
> >
> > > > 4)
From: Yuxue Liu
In the vp_vdpa_set_status function, when setting the device status to
VIRTIO_CONFIG_S_DRIVER_OK, the vp_vdpa_request_irq function may fail.
In such cases, the device status should not be set to DRIVER_OK. Add
exception printing to remind the user.
Signed-off-by: Yuxue Liu
---
On Thu, 21 Mar 2024 07:57:35 -0700
Jonathan Haslam wrote:
> Active uprobes are stored in an RB tree and accesses to this tree are
> dominated by read operations. Currently these accesses are serialized by
> a spinlock but this leads to enormous contention when large numbers of
> threads are
The udp_fail_queue_rcv_skb() tracepoint lacks any details on the source
and destination IP/port whereas this information can be critical in case
of UDP/syslog.
Signed-off-by: Balazs Scheidler
---
include/trace/events/udp.h | 29 -
net/ipv4/udp.c | 2 +-
From: Jason Xing
Introducing entry_saddr and entry_daddr parameters in this macro
for later use can help us record the reverse 4-tuple by analyzing
the 4-tuple of the incoming skb when receiving.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 21 +++--
1 file
>> >> -
>> >> v2->v3:
>> >> Some fixes according to
>> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home=
>/
>> >> 1. Change the tracking directory to/sys/kernel/tracking.
>> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>> >>
>> >> v1->v2:
>>
On Fri, Mar 22, 2024 at 02:25:57PM +0100, Wolfram Sang wrote:
> Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C
> v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
> appropriate terms. For some drivers, this means no more conversions are
> needed. For the
On 3/20/24 17:14, Michael S. Tsirkin wrote:
On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote:
On 3/20/24 10:49, Michael S. Tsirkin wrote:>
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 6f7e5010a673..79456706d0bd 100644
---
On Mon, Mar 25, 2024 at 12:05 PM Peilin He wrote:
>
> >> -
> >> v2->v3:
> >> Some fixes according to
> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
> >> 1. Change the tracking directory to/sys/kernel/tracking.
> >> 2. Adjust the layout of the TP-STRUCT_entry
From: Jason Xing
Put the macro into another standalone file for better extension.
Some tracepoints can use this common part in the future.
Signed-off-by: Jason Xing
---
include/trace/events/net_probe_common.h | 29 +
include/trace/events/tcp.h | 29
On 3/22/24 3:25 PM, Wolfram Sang wrote:
Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C
v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
appropriate terms. For some drivers, this means no more conversions are
needed. For the others more work needs to
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
From: Jason Xing
Before this, we miss some cases where the TCP layer could send rst but
we cannot trace it. So I decided to complete it :)
v2
1. fix spelling mistakes
Jason Xing (3):
trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters
trace: tcp: fully support trace_tcp_send_reset
tcp:
On Fri, 22 Mar 2024 03:21:21 -0700, Breno Leitao wrote:
> Hello Xuan,
>
> On Fri, Mar 22, 2024 at 10:00:22AM +0800, Xuan Zhuo wrote:
> > On Thu, 21 Mar 2024 09:54:30 -0700, Breno Leitao wrote:
>
> > > 4) Since the command above does not have a key, then the last
> > >scatter-gatter entry
>>
>> 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:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D
>> When an application
>> -
>> v2->v3:
>> Some fixes according to
>> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
>> 1. Change the tracking directory to/sys/kernel/tracking.
>> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>>
>> v1->v2:
>> Some fixes according to
>>
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/sock.h | 18
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/sock.h | 17
From: Jason Xing
Using the macro for other tracepoints use to be more concise.
No functional change.
Jason Xing (3):
trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
trace: use TP_STORE_ADDRS() macro in inet_sk_error_report()
trace: use TP_STORE_ADDRS() macro in
1 - 100 of 107 matches
Mail list logo
