All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCHv4 02/13] uprobes/x86: Remove struct uprobe_trampoline object
Date: Wed, 24 Jun 2026 16:36:23 +0200	[thread overview]
Message-ID: <ajvrZ_mMXnKrWf7h@redhat.com> (raw)
In-Reply-To: <20260526205840.173790-3-jolsa@kernel.org>

On 05/26, Jiri Olsa wrote:
>
> Removing struct uprobe_trampoline object and it's tracking code,
> because it's not needed. We can do same thing directly on top of
> struct vm_area_struct objects.
>
> This makes the code simpler and allows easy propagation of the
> trampoline vma object into child process in following change.
>
> Note the original code called destroy_uprobe_trampoline if the
> optimiation failed, but it only freed the struct uprobe_trampoline
> object, not the vma. The new vma leak is fixed in following change.
>
> Acked-by: Andrii Nakryiko <andrii@kernel.org>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>

Reviewed-by: Oleg Nesterov <oleg@redhat.com>

---------------------------------------------------------------------
Although I can't convince myself I fully understand this code with or
without this patch ;)

A couple of questions below...

> -static struct uprobe_trampoline *create_uprobe_trampoline(unsigned long vaddr)
> +static struct vm_area_struct *get_uprobe_trampoline(struct mm_struct *mm, unsigned long vaddr)
>  {
> -	struct pt_regs *regs = task_pt_regs(current);
> -	struct mm_struct *mm = current->mm;
> -	struct uprobe_trampoline *tramp;
> +	VMA_ITERATOR(vmi, mm, 0);
>  	struct vm_area_struct *vma;
>
> -	if (!user_64bit_mode(regs))
> -		return NULL;
> +	if (vaddr > TASK_SIZE || vaddr < PAGE_SIZE)
> +		return ERR_PTR(-EINVAL);

Do we really need this check? It looks a bit confusing to me...
vaddr is bp_vaddr from handle_swbp(), it should be valid?

> +
> +	for_each_vma(vmi, vma) {
> +		if (!vma_is_special_mapping(vma, &tramp_mapping))
> +			continue;
> +		if (is_reachable_by_call(vma->vm_start, vaddr))
> +			return vma;
> +	}

Perhaps we can later optimize this code a bit? I mean something like

	start_reachable = ...;
	end_reachable = ...;

	VMA_ITERATOR(vmi, mm, start_reachable);

	for_each_vma(vmi, vma) {
		if (!vma_is_special_mapping(...))
			continue;
		if (vma->vm_start > end_reachable)
			break;
		return vma;
	}

>  static int __arch_uprobe_optimize(struct arch_uprobe *auprobe, struct mm_struct *mm,
>  				  unsigned long vaddr)
>  {
> -	struct uprobe_trampoline *tramp;
> -	struct vm_area_struct *vma;
> -	bool new = false;
> -	int err = 0;
> +	struct pt_regs *regs = task_pt_regs(current);
> +	struct vm_area_struct *vma, *tramp;
>
> +	if (!user_64bit_mode(regs))
> +		return -EINVAL;
>  	vma = find_vma(mm, vaddr);
>  	if (!vma)
>  		return -EINVAL;

I guess find_vma() can't fail, the caller arch_uprobe_optimize() has called
copy_from_vaddr() under mmap_write_lock()... Nevermind.

Oleg.


  parent reply	other threads:[~2026-06-24 14:36 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 20:58 [PATCHv4 00/13] uprobes/x86: Fix red zone issue for optimized uprobes Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 01/13] uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline Jiri Olsa
2026-06-24 14:08   ` Oleg Nesterov
2026-05-26 20:58 ` [PATCHv4 02/13] uprobes/x86: Remove struct uprobe_trampoline object Jiri Olsa
2026-05-26 21:46   ` bot+bpf-ci
2026-05-27  9:58     ` Jiri Olsa
2026-06-01  8:31       ` Jiri Olsa
2026-06-24 14:36   ` Oleg Nesterov [this message]
2026-05-26 20:58 ` [PATCHv4 03/13] uprobes/x86: Allow to copy uprobe trampolines on fork Jiri Olsa
2026-05-26 21:46   ` bot+bpf-ci
2026-05-27  9:58     ` Jiri Olsa
2026-06-24 15:01   ` Oleg Nesterov
2026-05-26 20:58 ` [PATCHv4 04/13] uprobes/x86: Unmap trampoline vma object in case it's unused Jiri Olsa
2026-05-26 21:46   ` bot+bpf-ci
2026-05-27  9:57     ` Jiri Olsa
2026-06-24 15:36   ` Oleg Nesterov
2026-05-26 20:58 ` [PATCHv4 05/13] uprobes/x86: Move optimized uprobe from nop5 to nop10 Jiri Olsa
2026-06-08 20:46   ` Andrii Nakryiko
2026-06-09 11:44     ` Jiri Olsa
2026-06-09 16:43       ` Andrii Nakryiko
2026-06-10  8:18         ` Jiri Olsa
2026-06-10 18:02           ` Andrii Nakryiko
2026-05-26 20:58 ` [PATCHv4 06/13] libbpf: Change has_nop_combo to work on top of nop10 Jiri Olsa
2026-05-26 21:28   ` sashiko-bot
2026-05-27  9:57     ` Jiri Olsa
2026-05-26 21:46   ` bot+bpf-ci
2026-05-27  9:57     ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 07/13] libbpf: Detect uprobe syscall with new error Jiri Olsa
2026-05-26 21:36   ` sashiko-bot
2026-05-26 21:46   ` bot+bpf-ci
2026-05-26 20:58 ` [PATCHv4 08/13] selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch Jiri Olsa
2026-05-26 21:19   ` sashiko-bot
2026-05-26 21:46   ` bot+bpf-ci
2026-05-26 20:58 ` [PATCHv4 09/13] selftests/bpf: Change uprobe syscall tests to use nop10 Jiri Olsa
2026-05-26 21:15   ` sashiko-bot
2026-05-27  9:58     ` Jiri Olsa
2026-05-26 21:46   ` bot+bpf-ci
2026-05-27  9:58     ` Jiri Olsa
2026-05-27 10:30   ` Jakub Sitnicki
2026-05-26 20:58 ` [PATCHv4 10/13] selftests/bpf: Change uprobe/usdt trigger bench code " Jiri Olsa
2026-05-27 10:46   ` Jakub Sitnicki
2026-05-26 20:58 ` [PATCHv4 11/13] selftests/bpf: Add reattach tests for uprobe syscall Jiri Olsa
2026-05-27 11:32   ` Jakub Sitnicki
2026-05-28 11:10     ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 12/13] selftests/bpf: Add tests for uprobe nop10 red zone clobbering Jiri Olsa
2026-05-26 21:46   ` bot+bpf-ci
2026-05-27 10:26     ` Jiri Olsa
2026-05-28 12:46   ` Jakub Sitnicki
2026-05-26 20:58 ` [PATCHv4 13/13] selftests/bpf: Add tests for forked/cloned optimized uprobes Jiri Olsa
2026-05-28 13:00   ` Jakub Sitnicki
2026-06-01  8:31     ` Jiri Olsa
2026-06-04  6:59 ` [PATCHv4 00/13] uprobes/x86: Fix red zone issue for " Jiri Olsa
2026-06-08 20:48   ` Andrii Nakryiko
2026-06-23 19:11   ` Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ajvrZ_mMXnKrWf7h@redhat.com \
    --to=oleg@redhat.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jolsa@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.