From: Greg KH <greg@kroah.com>
To: mhiramat@kernel.org
Cc: stable@vger.kernel.org, JP Kobryn <inwardvessel@gmail.com>
Subject: Re: [PATCH 6.6.y] kprobes: consistent rcu api usage for kretprobe holder
Date: Sat, 9 Dec 2023 13:20:09 +0100 [thread overview]
Message-ID: <2023120932-follow-willow-32f3@gregkh> (raw)
In-Reply-To: <20231206015711.39492-1-mhiramat@kernel.org>
On Wed, Dec 06, 2023 at 10:57:11AM +0900, mhiramat@kernel.org wrote:
> From: JP Kobryn <inwardvessel@gmail.com>
>
> It seems that the pointer-to-kretprobe "rp" within the kretprobe_holder is
> RCU-managed, based on the (non-rethook) implementation of get_kretprobe().
> The thought behind this patch is to make use of the RCU API where possible
> when accessing this pointer so that the needed barriers are always in place
> and to self-document the code.
>
> The __rcu annotation to "rp" allows for sparse RCU checking. Plain writes
> done to the "rp" pointer are changed to make use of the RCU macro for
> assignment. For the single read, the implementation of get_kretprobe()
> is simplified by making use of an RCU macro which accomplishes the same,
> but note that the log warning text will be more generic.
>
> I did find that there is a difference in assembly generated between the
> usage of the RCU macros vs without. For example, on arm64, when using
> rcu_assign_pointer(), the corresponding store instruction is a
> store-release (STLR) which has an implicit barrier. When normal assignment
> is done, a regular store (STR) is found. In the macro case, this seems to
> be a result of rcu_assign_pointer() using smp_store_release() when the
> value to write is not NULL.
>
> Link: https://lore.kernel.org/all/20231122132058.3359-1-inwardvessel@gmail.com/
>
> Fixes: d741bf41d7c7 ("kprobes: Remove kretprobe hash")
> Cc: stable@vger.kernel.org
> Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> (cherry picked from commit d839a656d0f3caca9f96e9bf912fd394ac6a11bc)
> ---
> include/linux/kprobes.h | 8 +++-----
> kernel/kprobes.c | 4 ++--
> 2 files changed, 5 insertions(+), 7 deletions(-)
Did you build this? It breaks the build in 6.6.y in horrible ways:
./include/linux/kprobes.h:145:33: error: field ‘pool’ has incomplete type
145 | struct objpool_head pool;
| ^~~~
I'll drop this, can you please provide a working version?
thanks,
greg k-h
next prev parent reply other threads:[~2023-12-09 12:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-03 13:38 FAILED: patch "[PATCH] kprobes: consistent rcu api usage for kretprobe holder" failed to apply to 6.6-stable tree gregkh
2023-12-06 1:57 ` [PATCH 6.6.y] kprobes: consistent rcu api usage for kretprobe holder mhiramat
2023-12-09 12:20 ` Greg KH [this message]
2023-12-11 1:28 ` Masami Hiramatsu
2023-12-11 2:55 ` [PATCH 6.6.y v2] " mhiramat
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=2023120932-follow-willow-32f3@gregkh \
--to=greg@kroah.com \
--cc=inwardvessel@gmail.com \
--cc=mhiramat@kernel.org \
--cc=stable@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