Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200805230852.GA28727@paulmck-ThinkPad-P72>
In-Reply-To: <20200805230852.GA28727@paulmck-ThinkPad-P72>
From:   Marco Elver <elver@google.com>
Date:   Thu, 6 Aug 2020 12:31:36 +0200
Message-ID: <CANpmjNPxzOFC+VQujipFaPmAV8evU2LnB4X-iXuHah45o-7pfw@mail.gmail.com>
Subject: Re: Finally starting on short RCU grace periods, but...
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Kostya Serebryany <kcc@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        kasan-dev <kasan-dev@googlegroups.com>,
        Alexander Potapenko <glider@google.com>,
        Andrey Konovalov <andreyknvl@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

+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