lkml.org 
[lkml]   [2020]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Finally starting on short RCU grace periods, but...
+Cc kasan-dev

On Thu, 6 Aug 2020 at 01:08, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Hello!
>
> If I remember correctly, one of you asked for a way to shorten RCU
> grace periods so that KASAN would have a better chance of detecting bugs
> such as pointers being leaked out of RCU read-side critical sections.
> I am finally starting entering and testing code for this, but realized
> that I had forgotten a couple of things:
>
> 1. I don't remember exactly who asked, but I suspect that it was
> Kostya. I am using his Reported-by as a placeholder for the
> moment, but please let me know if this should be adjusted.

It certainly was not me.

> 2. Although this work is necessary to detect situtions where
> call_rcu() is used to initiate a grace period, there already
> exists a way to make short grace periods that are initiated by
> synchronize_rcu(), namely, the rcupdate.rcu_expedited kernel
> boot parameter. This will cause all calls to synchronize_rcu()
> to act like synchronize_rcu_expedited(), resulting in about 2-3
> orders of magnitude reduction in grace-period latency on small
> systems (say 16 CPUs).
>
> In addition, I plan to make a few other adjustments that will
> increase the probability of KASAN spotting a pointer leak even in the
> rcupdate.rcu_expedited case.

Thank you, that'll be useful I think.

> But if you would like to start this sort of testing on current mainline,
> rcupdate.rcu_expedited is your friend!

Do any of you remember some bugs we missed due to this? Can we find
them if we add this option?

Thanks,
-- Marco

\
 
 \ /
  Last update: 2020-08-06 12:33    [W:0.072 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site