On Tue, Jun 24, 2025 at 09:50:50PM -0700, Andrew Morton wrote:
> On Wed, 25 Jun 2025 08:25:35 +0530 Anshuman Khandual
> wrote:
>
> > ust wondering which tree-branch this series applies ? Tried all the usual
> > ones but could not apply the series cleanly.
> >
>
On Thu, 5 Jun 2025 15:23:34 +0200
Jiri Olsa wrote:
> Making update_ref_ctr call in uprobe_write conditional based
> on do_ref_ctr argument. This way we can use uprobe_write for
> instruction update without doing ref_ctr_offset update.
>
Can we just decouple this update from uprobe_write()?
If
On Thu, 5 Jun 2025 15:23:33 +0200
Jiri Olsa wrote:
> The uprobe_write has special path to restore the original page when we
> write original instruction back. This happens when uprobe_write detects
> that we want to write anything else but breakpoint instruction.
>
> Moving the detection away a
On Thu, 5 Jun 2025 15:23:32 +0200
Jiri Olsa wrote:
> Adding nbytes argument to uprobe_write and related functions as
> preparation for writing whole instructions in following changes.
>
> Also renaming opcode arguments to insn, which seems to fit better.
>
Looks good to me.
Acked-by: Masami
On Thu, 5 Jun 2025 15:23:31 +0200
Jiri Olsa wrote:
> Adding uprobe_write function that does what uprobe_write_opcode did
> so far, but allows to pass verify callback function that checks the
> memory location before writing the opcode.
>
> It will be used in following changes to implement speci
On 19/06/25 1:12 AM, Lorenzo Stoakes wrote:
> In future we intend to change the vm_flags_t type, so it isn't correct for
> architecture and driver code to assume it is unsigned long. Correct this
> assumption across the board.
>
> Overall, this patch does not introduce any functional change.
>
On 19/06/25 1:12 AM, Lorenzo Stoakes wrote:
> We abstract the type of the VMA flags to vm_flags_t, however in may places
> it is simply assumed this is unsigned long, which is simply incorrect.
>
> At the moment this is simply an incongruity, however in future we plan to
> change this type and
Hi Jiri,
Sorry I missed the series. Let me review it.
I think it should go through x86 tree because this is targetting
x86 code.
Thanks,
On Tue, 24 Jun 2025 10:36:29 +0200
Jiri Olsa wrote:
> ping
>
> On Tue, Jun 17, 2025 at 03:08:08PM +0200, Jiri Olsa wrote:
> > hi, ping
> >
> > thanks,
> >
On Thu, 5 Jun 2025 15:23:28 +0200
Jiri Olsa wrote:
> Currently unapply_uprobe takes mmap_read_lock, but it might call
> remove_breakpoint which eventually changes user pages.
>
> Current code writes either breakpoint or original instruction, so it can
> go away with read lock as explained in he
On 19/06/25 1:12 AM, Lorenzo Stoakes wrote:
> The core kernel code is currently very inconsistent in its use of
> vm_flags_t vs. unsigned long. This prevents us from changing the type of
> vm_flags_t in the future and is simply not correct, so correct this.
>
> While this results in rather a lo
On Wed, 25 Jun 2025 08:25:35 +0530 Anshuman Khandual
wrote:
> ust wondering which tree-branch this series applies ? Tried all the usual
> ones but could not apply the series cleanly.
>
> v6.16-rc3
> next-20250624
> mm-stable
> mm-unstable
It's now in mm-unstable if that helps.
branch this series applies ? Tried all the usual
ones but could not apply the series cleanly.
v6.16-rc3
next-20250624
mm-stable
mm-unstable
b4 am cover.1750274467.git.lorenzo.stoa...@oracle.com
git am ./20250618_lorenzo_stoakes_use_vm_flags_t_consistently.mbx
- Anshuman
On Tue, 24 Jun 2025 17:00:21 +0200
Peter Zijlstra wrote:
> On Tue, Jun 24, 2025 at 10:55:38AM -0400, Steven Rostedt wrote:
>
> > > Which is somewhat inconsistent;
> > >
> > > __clear_bit()/__set_bit()
> >
> > Hmm, are the above non-atomic?
>
> Yes, ctags or any other code browser of you
On Tue, 2025-06-24 at 09:36 +0200, Nam Cao wrote:
> On Wed, May 14, 2025 at 10:43:11AM +0200, Gabriele Monaco wrote:
> > diff --git a/kernel/trace/rv/monitors/tss/tss_trace.h
> > b/kernel/trace/rv/monitors/sts/sts_trace.h
> > similarity index 67%
> > rename from kernel/trace/rv/monitors/tss/tss_
On Thu, 19 Jun 2025 11:11:21 +0200
Peter Zijlstra wrote:
> I feel much of this complication stems from the fact you're wanting to
> make this perhaps too generic.
I want to make it work for perf, ftrace, LTTng and BPF, where each has
their own requirements, which tends to force making it generic
On Tue, Jun 24, 2025 at 9:13 AM Tao Chen wrote:
>
> 在 2025/6/24 23:46, Andrii Nakryiko 写道:
> > On Tue, Jun 24, 2025 at 1:41 AM Tao Chen wrote:
> >>
> >> 在 2025/6/24 16:16, Jiri Olsa 写道:
> >>> On Mon, Jun 23, 2025 at 01:59:18PM -0700, Andrii Nakryiko wrote:
> On Mon, Jun 23, 2025 at 10:56 AM
On Wed, 18 Jun 2025 20:46:20 +0200
Peter Zijlstra wrote:
> > static __always_inline void unwind_exit_to_user_mode(void)
> > {
> > if (unlikely(current->unwind_info.cache))
> > current->unwind_info.cache->nr_entries = 0;
> > + current->unwind_info.timestamp = 0;
>
> Surely c
On Tue, 24 Jun 2025 14:38:46 +0800
Edward Adam Davis wrote:
> If the processing of the tr->events loop fails, the filter that has been
> added to filter_head will be released twice in free_filter_list(&head->rcu)
> and __free_filter(filter).
>
> After adding the filter of tr->events, add the fil
On Tue, Jun 24, 2025 at 10:55:38AM -0400, Steven Rostedt wrote:
> > Which is somewhat inconsistent;
> >
> > __clear_bit()/__set_bit()
>
> Hmm, are the above non-atomic?
Yes, ctags or any other code browser of you choice should get you to
their definition, which has a comment explaining the no
On Wed, Jun 18, 2025 at 08:42:54PM +0100, Lorenzo Stoakes wrote:
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -279,7 +279,7 @@ static struct sgx_encl_page *__sgx_encl_load_page(struct
> sgx_encl *encl,
>
> static struct sgx_encl_page *sgx_encl_load_page_in_
On Mon, 23 Jun 2025 09:31:17 -0700
Indu Bhagat wrote:
> >> Also, CFA here is Call-Frame-Address and RA Return-Address ?
> >
> > I believe so. Do you want me to add a comment?
> >
>
> If a comment is added, Canonical Frame Address will be more appropriate.
Thanks Indu,
Updated.
-- Steve
On Fri, 20 Jun 2025 10:15:42 +0200
Peter Zijlstra wrote:
> On Tue, Jun 10, 2025 at 08:54:29PM -0400, Steven Rostedt wrote:
>
>
> > void unwind_deferred_cancel(struct unwind_work *work)
> > {
> > + struct task_struct *g, *t;
> > +
> > if (!work)
> > return;
> >
> > guar
On Tue, 24 Jun 2025 17:50:53 +0200
Nam Cao wrote:
> I would like that. Ideally, the userspace tools only use tracepoints based
> on available_monitors.
>
> However, people may not do that, and just use tracepoints directly.
>
> You could argue that those tools are not correctly designed. Theref
On Tue, 24 Jun 2025 14:38:46 +0800
Edward Adam Davis wrote:
> If the processing of the tr->events loop fails, the filter that has been
> added to filter_head will be released twice in free_filter_list(&head->rcu)
> and __free_filter(filter).
>
> After adding the filter of tr->events, add the fil
On Mon, 23 Jun 2025 16:58:28 -0700
syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:86731a2a651e Linux 6.16-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1611eb0c58
According to the above, this came right after
在 2025/6/24 23:46, Andrii Nakryiko 写道:
On Tue, Jun 24, 2025 at 1:41 AM Tao Chen wrote:
在 2025/6/24 16:16, Jiri Olsa 写道:
On Mon, Jun 23, 2025 at 01:59:18PM -0700, Andrii Nakryiko wrote:
On Mon, Jun 23, 2025 at 10:56 AM Alexei Starovoitov
wrote:
On Mon, Jun 23, 2025 at 6:44 AM Tao Chen wro
On Tue, Jun 24, 2025 at 04:44:49PM +0200, Gabriele Monaco wrote:
> As you mentioned, nobody is likely relying on those tracepoints names
> at the moment, but I would rather be cautious basing userspace tools on
> some monitors to exist at all.
>
> In my opinion, RV tracepoints are useful as an alt
On Tue, Jun 24, 2025 at 1:41 AM Tao Chen wrote:
>
> 在 2025/6/24 16:16, Jiri Olsa 写道:
> > On Mon, Jun 23, 2025 at 01:59:18PM -0700, Andrii Nakryiko wrote:
> >> On Mon, Jun 23, 2025 at 10:56 AM Alexei Starovoitov
> >> wrote:
> >>>
> >>> On Mon, Jun 23, 2025 at 6:44 AM Tao Chen wrote:
>
>
在 2025/6/24 16:16, Jiri Olsa 写道:
On Mon, Jun 23, 2025 at 01:59:18PM -0700, Andrii Nakryiko wrote:
On Mon, Jun 23, 2025 at 10:56 AM Alexei Starovoitov
wrote:
On Mon, Jun 23, 2025 at 6:44 AM Tao Chen wrote:
Alexei suggested, 'link_type' can be more precise and differentiate
for human in fdin
ping
On Tue, Jun 17, 2025 at 03:08:08PM +0200, Jiri Olsa wrote:
> hi, ping
>
> thanks,
> jirka
>
> On Thu, Jun 05, 2025 at 03:23:27PM +0200, Jiri Olsa wrote:
> > hi,
> > this patchset adds support to optimize usdt probes on top of 5-byte
> > nop instruction.
> >
> > The generic approach (optimi
On Mon, Jun 23, 2025 at 01:59:18PM -0700, Andrii Nakryiko wrote:
> On Mon, Jun 23, 2025 at 10:56 AM Alexei Starovoitov
> wrote:
> >
> > On Mon, Jun 23, 2025 at 6:44 AM Tao Chen wrote:
> > >
> > > Alexei suggested, 'link_type' can be more precise and differentiate
> > > for human in fdinfo. In fac
On Wed, May 14, 2025 at 10:43:11AM +0200, Gabriele Monaco wrote:
> diff --git a/kernel/trace/rv/monitors/tss/tss_trace.h
> b/kernel/trace/rv/monitors/sts/sts_trace.h
> similarity index 67%
> rename from kernel/trace/rv/monitors/tss/tss_trace.h
> rename to kernel/trace/rv/monitors/sts/sts_trace.h
>
32 matches
Mail list logo
