在 2024/8/7 18:17, Oleg Nesterov 写道:
> So. Liao, I am sorry, but I dislike your patch/approach in any case.
>
> UTASK_SSTEP_DENY_SIGNAL complicates the state machine. And I don't like the
> fact
> that set_thread_flag(TIF_SIGPENDING) is called twice, from handle_singlestep()
> and uprobe_post_s
Hello All,
This series adds deferred probe functionality in the TI's Remoteproc
drivers. The remoteproc drivers are dependent on the omap-mailbox driver
for mbox functionalities. Sometimes, the remoteproc driver could be
probed before the mailbox driver leading to rproc boot failures. Thus,
defer
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting
to free on error paths.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 16 +---
1 file changed, 5 insertions(+
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This also
allows to defer remoteproc driver's probe if mailbox is not probed yet.
Signed-off-by: Bele
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This also
allows to defer remoteproc driver's probe if mailbox is not probed yet.
Signed-off-by: Bele
在 2024/8/8 1:31, Andrii Nakryiko 写道:
> On Wed, Aug 7, 2024 at 10:11 AM Oleg Nesterov wrote:
>>
>> On 08/07, Andrii Nakryiko wrote:
>>>
>>> Yes, I was waiting for more of Peter's comments, but I guess I'll just
>>> send a v2 today.
>>
>> OK,
>>
>>> I'll probably include the SRCU+timeout logic fo
Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
accesses during the hang.
Invalid read at addr 0x102877002, size 2, region '(null)', reason:
rejected
Invalid write at addr 0x102877A44, size 2, region '(null)', reason:
rejected
...
It was traced down
We used to call irq_bypass_unregister_producer() in
vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the
token pointer is still valid or not.
Actually, we use the eventfd_ctx as the token so the life cycle of the
token should be bound to the VHOST_SET_VRING_CALL instead of
vhost_
On Thu, Aug 8, 2024 at 10:56 AM Jason Wang wrote:
>
> On Tue, Aug 6, 2024 at 10:45 PM Dragos Tatulea wrote:
> >
> >
> >
> > On 06.08.24 10:18, Dragos Tatulea wrote:
> > > (Re-sending. I messed up the previous message, sorry about that.)
> > >
> > > On 06.08.24 04:57, Jason Wang wrote:
> > >> On M
Hi Andrii and Oleg.
This patch sent by me two weeks ago also aim to optimize the performance of
uprobe
on arm64. I notice recent discussions on the performance and scalability of
uprobes
within the mailing list. Considering this interest, I've added you and other
relevant
maintainers to the CC
On Wed 2024-08-07 19:46:31, Song Liu wrote:
>
>
> > On Aug 7, 2024, at 7:58 AM, zhang warden wrote:
> >
> >
> >> In my GCC built, we have suffixes like ".constprop.0", ".part.0",
> >> ".isra.0",
> >> and ".isra.0.cold".
> >
> > A fresher's eye, I met sometime when try to build a livepatch m
On Wed 2024-08-07 20:48:48, Song Liu wrote:
>
>
> > On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
> >
> > Hi,
> >
> > On Wed, Aug 7, 2024 at 3:08 AM Masami Hiramatsu wrote:
> >>
> >> On Wed, 7 Aug 2024 00:19:20 +
> >> Song Liu wrote:
> >>
> >>> Do you mean we do not want patch 3/3,
On 08/07, Andrii Nakryiko wrote:
>
> Ok, so it seems like rb_find_rcu() and rb_find_add_rcu() are not
> enough or are buggy. I managed to more or less reliably start
> reproducing a crash, which was bisected to exactly this change. My
> wild guess is that we'd need an rb_erase_rcu() variant or some
On 08/07, Andrii Nakryiko wrote:
>
> struct uprobe {
> - struct rb_node rb_node;/* node in the rb tree */
> + union {
> + struct rb_node rb_node;/* node in the rb tree
> */
> + struct rcu_head rcu;/* mutually ex
On Fri 2024-08-02 14:08:34, 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, users like k
On 08/08, Liao, Chang wrote:
>
> - pre_ssout() resets the deny signal flag
>
> - uprobe_deny_signal() sets the deny signal flag when TIF_SIGPENDING is
> cleared.
>
> - handle_singlestep() check the deny signal flag and restore TIF_SIGPENDING
> if necessary.
>
> Does this approach look corre
On Thu, Aug 8, 2024 at 10:58 AM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 2:52 PM Yongji Xie 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 w
On Thu, Aug 8, 2024 at 1:50 PM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 2:54 PM Yongji Xie wrote:
> >
> > On Wed, Aug 7, 2024 at 12:38 PM Jason Wang wrote:
> > >
> > > On Wed, Aug 7, 2024 at 11:13 AM Yongji Xie
> > > wrote:
> > > >
> > > > On Wed, Aug 7, 2024 at 10:39 AM Jason Wang wrote:
On 8/2/24 13:22, Andrew Davis wrote:
This is simpler and removes the need to assume the id length to be 1
digit, which then removes a W=1 compile warning about the same.
Signed-off-by: Andrew Davis
Acked/Tested-by: Hari Nagalla
---
drivers/remoteproc/keystone_remoteproc.c | 6 +-
1 fi
On 7/29/24 11:45, Andrew Davis wrote:
Module aliases are used by userspace to identify the correct module to
load for a detected hardware. The currently supported RPMSG device IDs for
this module include "rpmsg-raw", but the module alias is "rpmsg_chrdev".
Use the helper macro MODULE_DEVICE_TABL
Thu, Aug 08, 2024 at 09:51:41AM CEST, kirill.shute...@linux.intel.com wrote:
>Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
>accesses during the hang.
>
> Invalid read at addr 0x102877002, size 2, region '(null)', reason:
> rejected
> Invalid write at addr 0x102
On Thu, Aug 08, 2024 at 10:51:41AM +0300, Kirill A. Shutemov wrote:
> Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
> accesses during the hang.
>
> Invalid read at addr 0x102877002, size 2, region '(null)', reason:
> rejected
> Invalid write at addr 0x102877A44
On Thu, Aug 08, 2024 at 01:37:42PM +0200, Jiri Pirko wrote:
> Thu, Aug 08, 2024 at 09:51:41AM CEST, kirill.shute...@linux.intel.com wrote:
> >Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
> >accesses during the hang.
> >
> > Invalid read at addr 0x102877002, size 2, regi
在 2024/8/8 18:28, Oleg Nesterov 写道:
> On 08/08, Liao, Chang wrote:
>>
>> - pre_ssout() resets the deny signal flag
>>
>> - uprobe_deny_signal() sets the deny signal flag when TIF_SIGPENDING is
>> cleared.
>>
>> - handle_singlestep() check the deny signal flag and restore
>> TIF_SIGPENDIN
On Thu, Aug 08, 2024 at 08:10:34AM -0400, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2024 at 10:51:41AM +0300, Kirill A. Shutemov wrote:
> > Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
> > accesses during the hang.
> >
> > Invalid read at addr 0x102877002, size 2, re
On 08/08, Liao, Chang wrote:
>
>
> 在 2024/8/8 18:28, Oleg Nesterov 写道:
> > --- x/kernel/events/uprobes.c
> > +++ x/kernel/events/uprobes.c
> > @@ -2308,9 +2308,10 @@ static void handle_singlestep(struct upr
> > utask->state = UTASK_RUNNING;
> > xol_free_insn_slot(current);
> >
> > - spin_
On 07/31, Andrii Nakryiko wrote:
>
> static DEFINE_RWLOCK(uprobes_treelock); /* serialize rbtree access */
> +static seqcount_rwlock_t uprobes_seqcount =
> SEQCNT_RWLOCK_ZERO(uprobes_seqcount, &uprobes_treelock);
Just noticed... Why seqcount_rwlock_t?
find_uprobe_rcu() doesn't use read_seq
On 8/8/24 2:41 AM, Beleswar Padhi wrote:
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting
to free on error paths.
Signed-off-by: Beleswar Padhi
---
LGTM
Reviewed-by: Andrew Davis
drivers/remot
On 08/07, Andrii Nakryiko wrote:
>
> So, any ideas how we can end up with "corrupted" root on lockless
> lookup with rb_find_rcu()?
I certainly can't help ;) I know ABSOLUTELY NOTHING about rb or any
other tree.
But,
> This seems to be the very first lockless
> RB-tree lookup use case in the tre
On 08/07, Andrii Nakryiko wrote:
>
> @@ -1127,18 +1105,30 @@ 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;
> - } else
On Thu, Aug 08, 2024 at 04:15:25PM +0300, Kirill A. Shutemov wrote:
> On Thu, Aug 08, 2024 at 08:10:34AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Aug 08, 2024 at 10:51:41AM +0300, Kirill A. Shutemov wrote:
> > > Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
> > > accesse
> On Aug 8, 2024, at 3:20 AM, Petr Mladek wrote:
>
> On Fri 2024-08-02 14:08:34, 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
> On Aug 8, 2024, at 2:48 AM, Petr Mladek wrote:
>
> On Wed 2024-08-07 19:46:31, Song Liu wrote:
>>
>>
>>> On Aug 7, 2024, at 7:58 AM, zhang warden wrote:
>>>
>>>
In my GCC built, we have suffixes like ".constprop.0", ".part.0",
".isra.0",
and ".isra.0.cold".
>>>
>>> A fr
> On Aug 8, 2024, at 2:59 AM, Petr Mladek wrote:
>
> On Wed 2024-08-07 20:48:48, Song Liu wrote:
>>
>>
>>> On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Aug 7, 2024 at 3:08 AM Masami Hiramatsu wrote:
On Wed, 7 Aug 2024 00:19:20 +
Song Liu
On Thu, Aug 08, 2024 at 11:03:30AM -0400, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2024 at 04:15:25PM +0300, Kirill A. Shutemov wrote:
> > On Thu, Aug 08, 2024 at 08:10:34AM -0400, Michael S. Tsirkin wrote:
> > > On Thu, Aug 08, 2024 at 10:51:41AM +0300, Kirill A. Shutemov wrote:
> > > > Hongyu
Thu, Aug 08, 2024 at 02:11:09PM CEST, kirill.shute...@linux.intel.com wrote:
>On Thu, Aug 08, 2024 at 01:37:42PM +0200, Jiri Pirko wrote:
>> Thu, Aug 08, 2024 at 09:51:41AM CEST, kirill.shute...@linux.intel.com wrote:
>> >Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
>> >acc
On Thu, 8 Aug 2024 11:59:00 +0200
Petr Mladek wrote:
> On Wed 2024-08-07 20:48:48, Song Liu wrote:
> >
> >
> > > On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Aug 7, 2024 at 3:08 AM Masami Hiramatsu
> > > wrote:
> > >>
> > >> On Wed, 7 Aug 2024 00:19
Oh yes. That sounds like a good idea. Let me update the patch with it.
Thanks,
Takaya Saeki
On Thu, Aug 8, 2024 at 3:20 AM Oleg Nesterov wrote:
>
> On 08/07, Andrii Nakryiko wrote:
> >
> > struct uprobe {
> > - struct rb_node rb_node;/* node in the rb tree */
> > + union {
> > + struct rb_node rb_node;/* node in the rb
> > tree */
>
On Thu, Aug 8, 2024 at 7:29 AM Oleg Nesterov wrote:
>
> On 08/07, Andrii Nakryiko wrote:
> >
> > So, any ideas how we can end up with "corrupted" root on lockless
> > lookup with rb_find_rcu()?
>
> I certainly can't help ;) I know ABSOLUTELY NOTHING about rb or any
> other tree.
>
> But,
>
> > Thi
An important part of a production ready Linux kernel driver is
tracepoints. So to write production ready Linux kernel drivers in Rust,
we must be able to call tracepoints from Rust code. This patch series
adds support for calling tracepoints declared in C from Rust.
To use the tracepoint support,
Add just enough support for static key so that we can use it from
tracepoints. Tracepoints rely on `static_key_false` even though it is
deprecated, so we add the same functionality to Rust.
This patch only provides a generic implementation without code patching
(matching the one used when CONFIG_J
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header, and that this header is included in the input to bindgen.
Instead of calling __DO_TRACE directly, the exported rust_do_trace_
function calls an inline hel
This updates the Rust printing sample to invoke a tracepoint. This
ensures that we have a user in-tree from the get-go even though the
patch is being merged before its real user.
Signed-off-by: Alice Ryhl
---
MAINTAINERS| 1 +
include/trace/events/rust_sample.h | 31
To avoid duplication of inline asm between C and Rust, we need to
import the inline asm from the relevant `jump_label.h` header into Rust.
To make that easier, this patch updates the header files to expose the
inline asm via a new ARCH_STATIC_BRANCH_ASM macro.
The header files are all updated to d
To allow the Rust implementation of static_key_false to use runtime code
patching instead of the generic implementation, pull in the relevant
inline assembly from the jump_label.h header by running the C
preprocessor on a .rs.S file. Build rules are added for .rs.S files.
Since the relevant inline
On Thu, Aug 8, 2024 at 7:40 AM Oleg Nesterov wrote:
>
> On 08/07, Andrii Nakryiko wrote:
> >
> > @@ -1127,18 +1105,30 @@ void uprobe_unregister(struct uprobe *uprobe,
> > struct uprobe_consumer *uc)
> > int err;
> >
> > down_write(&uprobe->register_rwsem);
> > - if (WARN_ON(!consu
On Thu, Aug 8, 2024 at 9:58 AM Andrii Nakryiko
wrote:
>
> On Thu, Aug 8, 2024 at 3:20 AM Oleg Nesterov wrote:
> >
> > On 08/07, Andrii Nakryiko wrote:
> > >
> > > struct uprobe {
> > > - struct rb_node rb_node;/* node in the rb tree */
> > > + union {
> > > +
On 08.08.24 10:20, Jason Wang wrote:
> We used to call irq_bypass_unregister_producer() in
> vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the
> token pointer is still valid or not.
>
> Actually, we use the eventfd_ctx as the token so the life cycle of the
> token should be
On Thu, Aug 8, 2024 at 1:45 AM Liao, Chang wrote:
>
> Hi Andrii and Oleg.
>
> This patch sent by me two weeks ago also aim to optimize the performance of
> uprobe
> on arm64. I notice recent discussions on the performance and scalability of
> uprobes
> within the mailing list. Considering this i
Hi Liao,
To be honest I didn't even try to look at your patch, sorry.
Because I think it would be better to delay it in an case. Until Andrii
finishes/pushes his optimization changes which (in particular) include
find_active_uprobe_rcu/etc.
Then you can rebease and re-benchmark your patch on top
On Wed, Jul 31, 2024 at 08:25:30PM +0800, Zhihao Cheng wrote:
> The dax is only supportted on pfn type pmem devices since commit
> f467fee48da4 ("block: move the dax flag to queue_limits"), fix it
> by adding dax flag setting for the missed case.
s/supportted/supported
How about adding failure me
The dax is only supported on pfn type pmem devices since commit
f467fee48da4 ("block: move the dax flag to queue_limits"). Trying
to mount DAX filesystem fails with this error:
mount: : wrong fs type, bad option, bad superblock on /dev/pmem7,
missing codepage or helper program, or other
From: Steven Rostedt
When running the following:
# cd /sys/kernel/tracing/
# echo 1 > events/sched/sched_waking/enable
# echo 1 > events/sched/sched_switch/enable
# echo 0 > tracing_on
# dd if=per_cpu/cpu0/trace_pipe_raw of=/tmp/raw0.dat
The dd task would get stuck in an infinite loop in t
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: can not start core 1 before core 0'.
This was happening due to some scheduling between prepare and start
callback. The probe function waits for event, which is getting
triggered
Since clearing a bit in thread_info is an atomic operation, the spinlock
is redundant and can be removed, reducing lock contention is good for
performance.
Acked-by: Oleg Nesterov
Signed-off-by: Liao Chang
---
kernel/events/uprobes.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/e
This patch introduces a flag to track TIF_SIGPENDING is suppress
temporarily during the uprobe single-step. Upon uprobe singlestep is
handled and the flag is confirmed, it could resume the TIF_SIGPENDING
directly without acquiring the siglock in most case, then reducing
contention and improving ove
The profiling result of BPF selftest on ARM64 platform reveals the
significant contention on the current->sighand->siglock is the
scalability bottleneck. The reason is also very straightforward that all
producer threads of benchmark have to contend the spinlock mentioned to
resume the TIF_SIGPENDIN
Hello,
sorry to join late at the party.
Il giorno gio 8 ago 2024 alle ore 11:59 Petr Mladek
ha scritto:
>
> On Wed 2024-08-07 20:48:48, Song Liu wrote:
> >
> >
> > > On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Aug 7, 2024 at 3:08 AM Masami Hiramatsu
> >
在 2024/8/9 2:49, Oleg Nesterov 写道:
> Hi Liao,
>
> To be honest I didn't even try to look at your patch, sorry.
>
> Because I think it would be better to delay it in an case. Until Andrii
> finishes/pushes his optimization changes which (in particular) include
> find_active_uprobe_rcu/etc.
>
>
60 matches
Mail list logo
