Introduce tracepoints to allow tracing the GLINK packets being exchanged
with other subsystems. This is useful for debugging both interaction
with remote processors and client driver issues, as well as tracking
latency through the communication stack.
Channel events are traced with both local and
The operation of advancing the FIFO receive pointer is sprinkled between
the interrupt handler itself, and functions being called from this.
Push all the RX advancement operations to the individual handlers, to
unify the style across the handling of the various messages.
Signed-off-by: Bjorn Ande
Align the qcom_glink_send_close_ack() arguments with other functions to
take the struct glink_channel, so that the upcoming tracepoint patch can
access the channel attributes.
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 6 +++---
1 file changed, 3 insertions(+), 3 dele
When debugging interaction with remoteproc, do performance measurments
and fix client bugs, it turns out to be very useful to have tracepoints
throughout GLINK, so introduce this.
Signed-off-by: Bjorn Andersson
---
Bjorn Andersson (3):
rpmsg: glink: Tidy up RX advance handling
rpmsg:
On Tue, Aug 6, 2024 at 10:28 AM Jason Wang wrote:
>
> On Mon, Aug 5, 2024 at 6:42 PM Yongji Xie wrote:
> >
> > On Mon, Aug 5, 2024 at 4:24 PM Jason Wang wrote:
> > >
> > > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > > >
> > > > Barry said [1]:
> > > >
> > > > """
> > > > mm doesn't sup
在 2024/8/2 17:24, Oleg Nesterov 写道:
> On 08/02, Liao, Chang wrote:
>>
>>
>> 在 2024/8/1 22:06, Oleg Nesterov 写道:
>>> On 08/01, Liao Chang wrote:
@@ -2276,22 +2277,25 @@ static void handle_singlestep(struct uprobe_task
*utask, struct pt_regs *regs)
int err = 0;
On Mon, Aug 5, 2024 at 11:59 PM Dragos Tatulea wrote:
>
> On 05.08.24 05:17, Jason Wang wrote:
> > On Fri, Aug 2, 2024 at 2:51 PM Dragos Tatulea wrote:
> >>
> >> On Fri, 2024-08-02 at 11:29 +0800, Jason Wang wrote:
> >>> On Thu, Aug 1, 2024 at 11:38 PM Dragos Tatulea
> >>> wrote:
>
>
On Mon, Aug 5, 2024 at 8:21 PM Jason Wang wrote:
>
> Barry said [1]:
>
> """
> mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> __GFP_NOFAIL without direct reclamation may just result in a busy
> loop within non-sleepable contexts.
> ""“
the current code will result in returnin
On Mon, Aug 5, 2024 at 6:42 PM Yongji Xie wrote:
>
> On Mon, Aug 5, 2024 at 4:24 PM Jason Wang wrote:
> >
> > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > >
> > > Barry said [1]:
> > >
> > > """
> > > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> > > __GFP_NOFAIL wi
On Mon, Aug 5, 2024 at 4:26 PM Michael S. Tsirkin wrote:
>
> On Mon, Aug 05, 2024 at 04:21:06PM +0800, Jason Wang wrote:
> > Barry said [1]:
> >
> > """
> > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> > __GFP_NOFAIL without direct reclamation may just result in a busy
> > l
在 2024/8/6 4:01, Andrii Nakryiko 写道:
> On Fri, Aug 2, 2024 at 8:05 AM Andrii Nakryiko
> wrote:
>>
>> On Thu, Aug 1, 2024 at 7:41 PM Liao, Chang wrote:
>>>
>>>
>>>
>>> 在 2024/8/1 5:42, Andrii Nakryiko 写道:
From: Peter Zijlstra
With uprobe_unregister() having grown a synchronize_s
On Sun, Aug 4, 2024 at 10:00 AM Yunsheng Lin wrote:
>
> On 8/3/2024 1:00 AM, Alexander Duyck wrote:
>
> >>
> >>>
> >>> As far as your API extension and naming maybe you should look like
> >>> something like bio_vec and borrow the naming from that since that is
> >>> essentially what you are passin
On Fri, Jul 12, 2024 at 04:34:59PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4
trace_uprobe->nhit counter is not incremented atomically, so its value
is bogus in practice. On the other hand, it's actually a pretty big
uprobe scalability problem due to heavy cache line bouncing between CPUs
triggering the same uprobe.
Drop it and emit obviously unrealistic value in its stead
On Fri, Aug 2, 2024 at 8:05 AM Andrii Nakryiko
wrote:
>
> On Thu, Aug 1, 2024 at 7:41 PM Liao, Chang wrote:
> >
> >
> >
> > 在 2024/8/1 5:42, Andrii Nakryiko 写道:
> > > From: Peter Zijlstra
> > >
> > > With uprobe_unregister() having grown a synchronize_srcu(), it becomes
> > > fairly slow to call
Hi Masami,
On Mon, Aug 5, 2024 at 6:45 AM Masami Hiramatsu wrote:
>
> On Fri, 2 Aug 2024 14:08:34 -0700
> Song Liu wrote:
>
> > With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> > to avoid duplication. This causes confusion with users of kallsyms.
> > On one hand, users l
On Mon, Aug 5, 2024 at 8:59 AM Oleg Nesterov wrote:
>
> On 07/31, Andrii Nakryiko wrote:
> >
> > @@ -1120,17 +1098,19 @@ void uprobe_unregister(struct uprobe *uprobe,
> > struct uprobe_consumer *uc)
> > int err;
> >
> > down_write(&uprobe->register_rwsem);
> > - if (WARN_ON(!consu
On Mon, Aug 5, 2024 at 7:52 AM Oleg Nesterov wrote:
>
> LGTM, just a few notes...
>
> On 07/31, Andrii Nakryiko wrote:
> >
> > @@ -59,6 +61,7 @@ struct uprobe {
> > struct list_headpending_list;
> > struct uprobe_consumer *consumers;
> > struct inode*inode;
On Mon, Aug 5, 2024 at 6:44 AM Oleg Nesterov wrote:
>
> On 07/31, Andrii Nakryiko wrote:
> >
> > @@ -732,11 +776,13 @@ static struct uprobe *alloc_uprobe(struct inode
> > *inode, loff_t offset,
> > uprobe->ref_ctr_offset = ref_ctr_offset;
> > init_rwsem(&uprobe->register_rwsem);
> >
On 07/31, Andrii Nakryiko wrote:
>
> @@ -1120,17 +1098,19 @@ void uprobe_unregister(struct uprobe *uprobe, struct
> uprobe_consumer *uc)
> int err;
>
> down_write(&uprobe->register_rwsem);
> - if (WARN_ON(!consumer_del(uprobe, uc))) {
> - err = -ENOENT;
OK, I agree, th
On 05.08.24 05:17, Jason Wang wrote:
> On Fri, Aug 2, 2024 at 2:51 PM Dragos Tatulea wrote:
>>
>> On Fri, 2024-08-02 at 11:29 +0800, Jason Wang wrote:
>>> On Thu, Aug 1, 2024 at 11:38 PM Dragos Tatulea wrote:
The following workflow triggers the crash referenced below:
1) vhost
On Sun, 04 Aug 2024 06:59:06 +, Lin, Meng-Bo wrote:
> The dts and dtsi add support for msm8916 variant of Samsung Galaxy J3
> SM-J320YZ smartphone released in 2016.
>
> Add a device tree for SM-J320YZ with initial support for:
>
> - GPIO keys
> - SDHCI (internal and external storage)
> - US
LGTM, just a few notes...
On 07/31, Andrii Nakryiko wrote:
>
> @@ -59,6 +61,7 @@ struct uprobe {
> struct list_headpending_list;
> struct uprobe_consumer *consumers;
> struct inode*inode; /* Also hold a ref to inode */
> + struct rcu_head
On Fri, 2 Aug 2024 14:08:34 -0700
Song Liu wrote:
> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> to avoid duplication. This causes confusion with users of kallsyms.
> On one hand, users like livepatch are required to match the symbols
> exactly. On the other hand, use
On 07/31, Andrii Nakryiko wrote:
>
> @@ -732,11 +776,13 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
> loff_t offset,
> uprobe->ref_ctr_offset = ref_ctr_offset;
> init_rwsem(&uprobe->register_rwsem);
> init_rwsem(&uprobe->consumer_rwsem);
> + RB_CLEAR_NODE(&upro
On Fri, 2 Aug 2024 17:09:12 +
Song Liu wrote:
> Hi Petr,
>
> > On Aug 2, 2024, at 8:45 AM, Petr Mladek wrote:
>
> [...]
>
> >
> > IMHO, it depends on the use case. Let's keep "ping_table/"
> > as an example. Why people would want to trace this function?
> > There might be various reason
From: Jianhui Zhou <912460...@qq.com>
Because ring_buffer_nr_pages() is not an inline function and user accesses
buffer->buffers[cpu]->nr_pages directly, the function ring_buffer_nr_pages
is removed.
Signed-off-by: Jianhui Zhou <912460...@qq.com>
---
include/linux/ring_buffer.h | 1 -
kernel/tr
"Benno Lossin" writes:
> On 02.08.24 12:27, Andreas Hindborg wrote:
>> "Benno Lossin" writes:
>>> On 01.08.24 17:11, Andreas Hindborg wrote:
"Benno Lossin" writes:
> On 01.08.24 15:40, Andreas Hindborg wrote:
>> "Benno Lossin" writes:
>>> On 01.08.24 13:29, Andreas Hindborg wr
On Mon, Aug 5, 2024 at 4:24 PM Jason Wang wrote:
>
> On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> >
> > Barry said [1]:
> >
> > """
> > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> > __GFP_NOFAIL without direct reclamation may just result in a busy
> > loop within non
Hi,
On Mon, Aug 05, 2024 at 08:44:11AM GMT, Ubisectech Sirius wrote:
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel 6.8. Attached to the
email were a PoC file of the issue.
Thanks for the report!
It
Hi Michael,
this series is marked as "Not Applicable" for the net-next tree:
https://patchwork.kernel.org/project/netdevbpf/patch/20240730-pinna-v4-2-5c9179164...@outlook.com/
Actually this is more about the virtio-vsock driver, so can you queue
this on your tree?
Thanks,
Stefano
On Tue, Jul
On Mon, Aug 05, 2024 at 04:21:06PM +0800, Jason Wang wrote:
> Barry said [1]:
>
> """
> mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> __GFP_NOFAIL without direct reclamation may just result in a busy
> loop within non-sleepable contexts.
> ""“
>
> Unfortuantely, we do that u
On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
>
> Barry said [1]:
>
> """
> mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> __GFP_NOFAIL without direct reclamation may just result in a busy
> loop within non-sleepable contexts.
> ""“
>
> Unfortuantely, we do that under read
Barry said [1]:
"""
mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
__GFP_NOFAIL without direct reclamation may just result in a busy
loop within non-sleepable contexts.
""“
Unfortuantely, we do that under read lock. A possible way to fix that
is to move the pages allocation out
Interrupts can be routed to maximal four virtual CPUs with one external
hardware interrupt. Add the extioi virt extension support so that
Interrupts can be routed to 256 vcpus on hypervisor mode.
Co-developed-by: Song Gao
Signed-off-by: Song Gao
Signed-off-by: Bibo Mao
---
.../arch/loongarch/i
Export kernel paravirt features to user space, so that VMM can control
the single paravirt feature. By default paravirt features will the same
with kvm supported features if VMM does not set it.
Also a new feature KVM_FEATURE_VIRT_EXTIOI is added which can be set from
user space. This feature indi
Function kvm_para_has_feature() is to detect supported paravirt features,
it can be used by device driver to detect and enable paravirt features,
such as extioi irqchip driver can detect KVM_FEATURE_VIRT_EXTIOI and do
some optimization.
Signed-off-by: Bibo Mao
---
arch/loongarch/include/asm/kvm_
KVM_FEATURE_VIRT_EXTIOI is paravirt feature defined with EXTIOI
interrupt controller, it can route interrupt to 256 CPUs and cpu
interrupt pin IP0-IP7. Now irqchip is emulated in user space rather than
kernel space, here interface is provided for VMM to pass this feature to
VMM hypervisor.
Also in
Similar with x86, when VM is detected, revert to a simple test-and-set
lock to avoid the horrors of queue preemption.
Tested on 3C5000 Dual-way machine with 32 cores and 2 numa nodes,
test case is kcbench on kernel mainline 6.10, the detailed command is
"kcbench --src /root/src/linux"
Performance
39 matches
Mail list logo
