linux-kernel - Re: [PATCH] kprobes: Fix to delay the kprobes jump optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210219181811.GY2743@paulmck-ThinkPad-P72>
Date:   Fri, 19 Feb 2021 10:18:11 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Uladzislau Rezki <urezki@...il.com>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Daniel Axtens <dja@...ens.net>,
        Frederic Weisbecker <frederic@...nel.org>,
        Neeraj Upadhyay <neeraju@...eaurora.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Michal Hocko <mhocko@...e.com>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>
Subject: Re: [PATCH] kprobes: Fix to delay the kprobes jump optimization

On Fri, Feb 19, 2021 at 12:27:51PM +0100, Uladzislau Rezki wrote:
> On Fri, Feb 19, 2021 at 12:23:57PM +0100, Uladzislau Rezki wrote:
> > On Fri, Feb 19, 2021 at 12:17:38PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2021-02-19 12:13:01 [+0100], Uladzislau Rezki wrote:
> > > > I or Paul will ask for a test once it is settled down :) Looks like
> > > > it is, so we should fix for v5.12.
> > > 
> > > Okay. Since Paul asked for powerpc test on v5.11-rc I wanted check if
> > > parts of it are also -stable material.

If Masami's patch works for the PowerPC guys on v5.10-rc7, then it can
be backported.  The patch making RCU Tasks initialize itself early won't
have any effect and can be left or reverted, as we choose.  The self-test
patch will need to be either adjusted or reverted.

However...

The root cause of this problem is that softirq only kind-of works
during a window of time during boot.  It works only if the number and
duration of softirq handlers during this time is small enough, for some
ill-defined notion of "small enough".  If there are too many, whatever
that means exactly, then we get failed attempt to awaken ksoftirqd, which
(sometimes!) results in a silent hang.  Which, as you pointed out earlier,
is a really obnoxious error message.  And any minor change could kick
us into silent-hang state because of the heuristics used to hand off
to ksoftirqd.  The straw that broke the camel's back and all that.

One approach would be to add WARN_ON_ONCE() so that if softirq tries
to awaken ksoftirqd before it is spawned, we get a nice obvious splat.
Unfortunately, this gives false positives because there is code that
needs a softirq handler to run eventually, but is OK with that handler
being delayed until some random point in the early_initcall() sequence.

Besides which, if we are going to add a check, why not use that check
just make things work by forcing handler execution to remain within the
softirq back-of-interrupt context instead of awakening a not-yet-spawned
ksoftirqd?  We can further prevent entry into dyntick-idle state until
the ksoftirqd kthreads have been spawned, which means that if softirq
handlers must be deferred, they will be resumed within one jiffy by the
next scheduler-clock interrupt.

Yes, this can allow softirq handlers to impose large latencies, but only
during early boot, long before any latency-sensitive applications can
possibly have been created.  So this does not seem like a real problem.

Am I missing something here?

							Thanx, Paul

> > OK, i see. It will be broken starting from v5.12-rc unless we fix it.
> > 
> Sorry it is broken since 5.11 kernel already, i messed it up.
> 
> --
> Vlad Rezki