From: "Günther Noack" <gnoack3000@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: linux-man@vger.kernel.org, alx@kernel.org
Subject: Re: [PATCHv4 7/7] man2: Add uretprobe syscall page
Date: Mon, 9 Sep 2024 22:26:37 +0200 [thread overview]
Message-ID: <20240909.b1e65f8b63ca@gnoack.org> (raw)
In-Reply-To: <20240502122313.1579719-8-jolsa@kernel.org>
Hello Jiri!
Sorry to revive this old thread with a meta-question...
We were discussing the workflow of using a single patch set for
sending man pages together with kernel changes, and Alejandro pointed
out on https://lwn.net/Articles/989398/ that you have been doing this
in the past on this and other threads.
I have been trying to reconstruct how you have done this, and so far,
my best guess is that the process is to:
1. `git fetch` the man pages project into the same local repo where
you keep the kernel tree;
2. prepare man page patches and kernel patches in that same repo
(probably using the git worktree feature);
3. git format-patch with --subject-prefix="PATCH bpf-next" and a
revision range that gives both "dotted ranges" at the same time, e.g.
git format-patch -v23 --cover-letter \
linux-master..mylinuxbranch man-master..mymanbranch
4. In the resulting mail files, hand-edit the subject prefix in the
man page commit, in addition to the cover letter.
Is that an accurate description of your process? Or am I overlooking
another trick or tool that I could use here? Is this a practice that
other people are using as well?
Thanks,
–-Günther
On Thu, May 02, 2024 at 02:23:13PM +0200, Jiri Olsa wrote:
> Adding man page for new uretprobe syscall.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> man2/uretprobe.2 | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 man2/uretprobe.2
>
> diff --git a/man2/uretprobe.2 b/man2/uretprobe.2
> new file mode 100644
> index 000000000000..08fe6a670430
> --- /dev/null
> +++ b/man2/uretprobe.2
> @@ -0,0 +1,45 @@
> +.\" Copyright (C) 2024, Jiri Olsa <jolsa@kernel.org>
> +.\"
> +.\" SPDX-License-Identifier: Linux-man-pages-copyleft
> +.\"
> +.TH uretprobe 2 (date) "Linux man-pages (unreleased)"
> +.SH NAME
> +uretprobe \- execute pending return uprobes
> +.SH SYNOPSIS
> +.nf
> +.B int uretprobe(void)
> +.fi
> +.SH DESCRIPTION
> +Kernel is using
> +.BR uretprobe()
> +syscall to trigger uprobe return probe consumers instead of using
> +standard breakpoint instruction.
> +
> +The uretprobe syscall is not supposed to be called directly by user, it's allowed
> +to be invoked only through user space trampoline provided by kernel.
> +When called from outside of this trampoline, the calling process will receive
> +.BR SIGILL .
> +
> +.SH RETURN VALUE
> +.BR uretprobe()
> +return value is specific for given architecture.
> +
> +.SH VERSIONS
> +This syscall is not specified in POSIX,
> +and details of its behavior vary across systems.
> +.SH STANDARDS
> +None.
> +.SH NOTES
> +.BR uretprobe()
> +syscall is initially introduced on x86-64 architecture, because doing syscall
> +is faster than doing breakpoint trap on it. It might be extended to other
> +architectures.
> +
> +.BR uretprobe()
> +syscall exists only to allow the invocation of return uprobe consumers.
> +It should
> +.B never
> +be called directly.
> +Details of the arguments (if any) passed to
> +.BR uretprobe ()
> +and the return value are specific for given architecture.
> --
> 2.44.0
>
next prev parent reply other threads:[~2024-09-09 20:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 12:23 [PATCHv4 bpf-next 0/7] uprobe: uretprobe speed up Jiri Olsa
2024-05-02 12:23 ` [PATCHv4 bpf-next 1/7] uprobe: Wire up uretprobe system call Jiri Olsa
2024-05-02 12:23 ` [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe Jiri Olsa
2024-05-03 11:34 ` Peter Zijlstra
2024-05-03 13:04 ` Jiri Olsa
2024-05-03 15:53 ` Edgecombe, Rick P
2024-05-03 19:18 ` Jiri Olsa
2024-05-03 19:38 ` Edgecombe, Rick P
2024-05-03 20:17 ` Jiri Olsa
2024-05-03 20:35 ` Edgecombe, Rick P
2024-05-06 10:56 ` Jiri Olsa
2024-05-03 23:01 ` Deepak Gupta
2024-05-02 12:23 ` [PATCHv4 bpf-next 3/7] selftests/bpf: Add uretprobe syscall test for regs integrity Jiri Olsa
2024-05-02 12:23 ` [PATCHv4 bpf-next 4/7] selftests/bpf: Add uretprobe syscall test for regs changes Jiri Olsa
2024-05-02 12:23 ` [PATCHv4 bpf-next 5/7] selftests/bpf: Add uretprobe syscall call from user space test Jiri Olsa
2024-05-02 16:33 ` Andrii Nakryiko
2024-05-02 12:23 ` [PATCHv4 bpf-next 6/7] selftests/bpf: Add uretprobe compat test Jiri Olsa
2024-05-02 16:35 ` Andrii Nakryiko
2024-05-02 12:23 ` [PATCHv4 7/7] man2: Add uretprobe syscall page Jiri Olsa
2024-05-02 13:43 ` Alejandro Colomar
2024-05-02 20:13 ` Jiri Olsa
2024-05-02 22:06 ` Alejandro Colomar
2024-09-09 20:26 ` Günther Noack [this message]
2024-09-10 8:11 ` Jiri Olsa
2024-05-02 16:43 ` [PATCHv4 bpf-next 0/7] uprobe: uretprobe speed up Andrii Nakryiko
2024-05-02 20:04 ` Jiri Olsa
2024-05-03 18:03 ` Andrii Nakryiko
2024-05-03 20:39 ` Jiri Olsa
2024-05-07 7:47 ` 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=20240909.b1e65f8b63ca@gnoack.org \
--to=gnoack3000@gmail.com \
--cc=alx@kernel.org \
--cc=jolsa@kernel.org \
--cc=linux-man@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox