[PATCH] rcu: tiny: record kvfree_call_rcu() call stack for KASAN

2 views
Skip to first unread message

Johannes Berg

unread,
May 27, 2022, 11:07:52 AM5/27/22
to r...@vger.kernel.org, kasa...@googlegroups.com, Johannes Berg
From: Johannes Berg <johann...@intel.com>

When running KASAN with Tiny RCU (e.g. under ARCH=um, where
a working KASAN patch is now available), we don't get any
information on the original kfree_rcu() (or similar) caller
when a problem is reported, as Tiny RCU doesn't record this.

Add the recording, which required pulling kvfree_call_rcu()
out of line for the KASAN case since the recording function
(kasan_record_aux_stack_noalloc) is neither exported, nor
can we include kasan.h into rcutiny.h.

without KASAN, the patch has no size impact (ARCH=um kernel):
text data bss dec hex filename
6151515 4423154 33148520 43723189 29b29b5 linux
6151515 4423154 33148520 43723189 29b29b5 linux + patch

with KASAN, the impact on my build was minimal:
text data bss dec hex filename
13915539 7388050 33282304 54585893 340ea25 linux
13911266 7392114 33282304 54585684 340e954 linux + patch
-4273 +4064 +-0 -209

Signed-off-by: Johannes Berg <johann...@intel.com>
---
include/linux/rcutiny.h | 11 ++++++++++-
kernel/rcu/tiny.c | 14 ++++++++++++++
2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 5fed476f977f..d84e13f2c384 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -38,7 +38,7 @@ static inline void synchronize_rcu_expedited(void)
*/
extern void kvfree(const void *addr);

-static inline void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
+static inline void __kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
{
if (head) {
call_rcu(head, func);
@@ -51,6 +51,15 @@ static inline void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
kvfree((void *) func);
}

+#ifdef CONFIG_KASAN_GENERIC
+void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
+#else
+static inline void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
+{
+ __kvfree_call_rcu(head, func);
+}
+#endif
+
void rcu_qs(void);

static inline void rcu_softirq_qs(void)
diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index 340b3f8b090d..58ff3721d975 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -217,6 +217,20 @@ bool poll_state_synchronize_rcu(unsigned long oldstate)
}
EXPORT_SYMBOL_GPL(poll_state_synchronize_rcu);

+#ifdef CONFIG_KASAN_GENERIC
+void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
+{
+ if (head) {
+ void *ptr = (void *) head - (unsigned long) func;
+
+ kasan_record_aux_stack_noalloc(ptr);
+ }
+
+ __kvfree_call_rcu(head, func);
+}
+EXPORT_SYMBOL_GPL(kvfree_call_rcu);
+#endif
+
void __init rcu_init(void)
{
open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
--
2.36.1

Dmitry Vyukov

unread,
May 27, 2022, 11:13:32 AM5/27/22
to Johannes Berg, r...@vger.kernel.org, kasa...@googlegroups.com, Johannes Berg, Paul E. McKenney
On Fri, 27 May 2022 at 17:07, Johannes Berg <joha...@sipsolutions.net> wrote:
>
> From: Johannes Berg <johann...@intel.com>
>
> When running KASAN with Tiny RCU (e.g. under ARCH=um, where
> a working KASAN patch is now available), we don't get any
> information on the original kfree_rcu() (or similar) caller
> when a problem is reported, as Tiny RCU doesn't record this.
>
> Add the recording, which required pulling kvfree_call_rcu()
> out of line for the KASAN case since the recording function
> (kasan_record_aux_stack_noalloc) is neither exported, nor
> can we include kasan.h into rcutiny.h.
>
> without KASAN, the patch has no size impact (ARCH=um kernel):
> text data bss dec hex filename
> 6151515 4423154 33148520 43723189 29b29b5 linux
> 6151515 4423154 33148520 43723189 29b29b5 linux + patch
>
> with KASAN, the impact on my build was minimal:
> text data bss dec hex filename
> 13915539 7388050 33282304 54585893 340ea25 linux
> 13911266 7392114 33282304 54585684 340e954 linux + patch
> -4273 +4064 +-0 -209
>
> Signed-off-by: Johannes Berg <johann...@intel.com>

From KASAN perspective:

Acked-by: Dmitry Vyukov <dvy...@google.com>

What tree should it go into? mm? rcu? +Paul
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20220527170743.04c21d235467.I1f79da0f90fb9b557ec34932136c656bc64b8fbf%40changeid.

Paul E. McKenney

unread,
May 27, 2022, 11:24:06 AM5/27/22
to Dmitry Vyukov, Johannes Berg, r...@vger.kernel.org, kasa...@googlegroups.com, Johannes Berg
On Fri, May 27, 2022 at 05:13:18PM +0200, Dmitry Vyukov wrote:
> On Fri, 27 May 2022 at 17:07, Johannes Berg <joha...@sipsolutions.net> wrote:
> >
> > From: Johannes Berg <johann...@intel.com>
> >
> > When running KASAN with Tiny RCU (e.g. under ARCH=um, where
> > a working KASAN patch is now available), we don't get any
> > information on the original kfree_rcu() (or similar) caller
> > when a problem is reported, as Tiny RCU doesn't record this.
> >
> > Add the recording, which required pulling kvfree_call_rcu()
> > out of line for the KASAN case since the recording function
> > (kasan_record_aux_stack_noalloc) is neither exported, nor
> > can we include kasan.h into rcutiny.h.
> >
> > without KASAN, the patch has no size impact (ARCH=um kernel):
> > text data bss dec hex filename
> > 6151515 4423154 33148520 43723189 29b29b5 linux
> > 6151515 4423154 33148520 43723189 29b29b5 linux + patch
> >
> > with KASAN, the impact on my build was minimal:
> > text data bss dec hex filename
> > 13915539 7388050 33282304 54585893 340ea25 linux
> > 13911266 7392114 33282304 54585684 340e954 linux + patch
> > -4273 +4064 +-0 -209
> >
> > Signed-off-by: Johannes Berg <johann...@intel.com>
>
> >From KASAN perspective:
>
> Acked-by: Dmitry Vyukov <dvy...@google.com>
>
> What tree should it go into? mm? rcu? +Paul

If Johannes is johill on IRC, I already agreed to take it. If not,
we might have dueling patches.

Ah, "Berg" -> "Hill". I never would have figured that out without
this hint. ;-)

Thanx, Paul

Paul E. McKenney

unread,
May 28, 2022, 7:53:01 PM5/28/22
to Dmitry Vyukov, Johannes Berg, r...@vger.kernel.org, kasa...@googlegroups.com, Johannes Berg
And applied with Dmitry's ack. It will show up on -rcu after my next
rebase.
Reply all
Reply to author
Forward
0 new messages