linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Korty <joe.korty@concurrent-rt.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Lee Jones <lee.jones@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Darren Hart <dvhart@infradead.org>,
	Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [BUG] 4.4.262: infinite loop in futex_unlock_pi (EAGAIN loop)
Date: Tue, 27 Jul 2021 18:19:50 -0400	[thread overview]
Message-ID: <20210727221950.GA51120@zipoli.concurrent-rt.com> (raw)
In-Reply-To: <YPl8nfZBjgmSnE7N@kroah.com>


 [ Added missing people to the cc: as listed in MAINTAINERS ]

On Thu, Jul 22, 2021 at 04:11:41PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 19, 2021 at 12:24:18PM -0400, Joe Korty wrote:
> > [BUG] 4.4.262: infinite loop in futex_unlock_pi (EAGAIN loop)
> > 
> >    [ replicator, attached ]
> >    [ workaround patch that crudely clears the loop, attached ]
> >    [ 4.4.256 does _not_ have this problem, 4.4.262 is known to have it ]
> > 
> > When a certain, secure-site application is run on 4.4.262, it locks up and
> > is unkillable.  Crash(8) and sysrq backtraces show that the application
> > is looping in the kernel in futex_unlock_pi.
> > 
> > Between 4.4.256 and .257, 4.4 got this 4.12 patch backported into it:
> > 
> >    73d786b ("[PATCH] futex: Rework inconsistent rt_mutex/futex_q state")
> > 
> > This patch has the following comment:
> > 
> >    The only problem is that this breaks RT timeliness guarantees. That
> >    is, consider the following scenario:
> > 
> >       T1 and T2 are both pinned to CPU0. prio(T2) > prio(T1)
> > 
> >         CPU0
> > 
> >         T1
> >           lock_pi()
> >           queue_me()  <- Waiter is visible
> >    
> >         preemption
> > 
> >         T2
> >           unlock_pi()
> >             loops with -EAGAIN forever
> > 
> >     Which is undesirable for PI primitives. Future patches will rectify
> >     this.
> > 
> > This describes the situation exactly.  To prove, we developed a little
> > kernel patch that, on loop detection, puts a message into the kernel log for
> > just the first occurrence, keeps a count of the number of occurrences seen
> > since boot, and tries to break out of the loop via usleep_range(1000,1000).
> > Note that the patch is not really needed for replication.  It merely shows,
> > by 'fixing' the problem, that it really is the EAGAIN loop that triggers
> > the lockup.
> > 
> > Along with this patch, we submit a replicator.  Running this replicator
> > with this patch, it can be seen that 4.4.256 does not have the problem.
> > 4.4.267 and the latest 4.4, 4.4.275, do.  In addition, 4.9.274 (tested
> > w/o the patch) does not have the problem.
> > 
> > >From this pattern there may be some futex fixup patch that was ported
> > back into 4.9 but failed to make it to 4.4.
> 
> Odd, I can't seem to find anything that we missed.  Can you dig to see
> if there is something that we need to do here so we can resolve this?
> 
> thanks,
> greg k-h


Hi Greg,

4.12 has these apparently-original patches:

  73d786b  futex: Rework inconsistent rt_mutex/futex_q state
  cfafcd1  futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

I have verified that the first commit, 73d786b, introduces
the futex_unlock_pi infinite loop bug into 4.12.  I have
also verified that the last commit, cfafcd1, fixes the bug.

4.9 has had both futex patches backported into it.
Verified that 4.9.276 does not suffer from the bug.

4.4 has had the first patch backported, as 394fc49, but
not the last.  I have verified that building a kernel at
394fc49 and at v4.4.276, the bug is seen, and at 394fc49^,
the bug is not present.

The missing commit, cfafcd1 in 4.12, is present in 4.9
as 13c98b0.  A visual spot-check of 13c98b0, as a patch,
with kernel/futex.c in 4.4.276 did not find any hunks of
13c98b0 present in 4.4.276's kernel/futex.c.

Regards,
Joe


  reply	other threads:[~2021-07-27 22:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 16:24 [BUG] 4.4.262: infinite loop in futex_unlock_pi (EAGAIN loop) Joe Korty
2021-07-22 14:11 ` Greg Kroah-Hartman
2021-07-27 22:19   ` Joe Korty [this message]
2021-07-28  6:07     ` Greg Kroah-Hartman
2021-07-28 13:51       ` Joe Korty
2021-07-28 16:15         ` Greg Kroah-Hartman

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=20210727221950.GA51120@zipoli.concurrent-rt.com \
    --to=joe.korty@concurrent-rt.com \
    --cc=bigeasy@linutronix.de \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).