All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Joe Korty <joe.korty@concurrent-rt.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>,
	stable <stable@vger.kernel.org>,
	Anna-Maria Gleixner <anna-maria@linutronix.de>,
	Mike Galbraith <efault@gmx.de>,
	Sasha Levin <sasha.levin@oracle.com>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4.4 00/11] Fix a potential infinite loop in RT futex-pi scenarios
Date: Sun, 8 Aug 2021 08:46:40 +0200	[thread overview]
Message-ID: <YQ990KMeDFspvGDQ@kroah.com> (raw)
In-Reply-To: <20210803005325.GA32484@zipoli.concurrent-rt.com>

On Mon, Aug 02, 2021 at 08:53:25PM -0400, Joe Korty wrote:
> On Mon, Aug 02, 2021 at 09:46:13PM +0800, Zhen Lei wrote:
> > Commit 73d786bd043e "futex: Rework inconsistent rt_mutex/futex_q state"
> > mentions that it could cause an infinite loop, and will fix it in the later
> > patches:
> > bebe5b514345f09 futex: Futex_unlock_pi() determinism
> > cfafcd117da0216 futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
> > 
> > But at the moment they're not backported. In a single-core environment, the
> > probability of triggering is high.
> > 
> > I also backported commit b4abf91047cf ("rtmutex: Make wait_lock irq safe"),
> > it fixes a potential deadlock problem. Although it hasn't actually been
> > triggered in our environment at the moment.
> > 
> > Other patches are used to resolve conflicts or fix problems caused by new
> > patches.
> > 
> > 
> > Anna-Maria Gleixner (1):
> >   rcu: Update documentation of rcu_read_unlock()
> > 
> > Mike Galbraith (1):
> >   futex: Handle transient "ownerless" rtmutex state correctly
> > 
> > Peter Zijlstra (6):
> >   futex: Cleanup refcounting
> >   futex,rt_mutex: Introduce rt_mutex_init_waiter()
> >   futex: Pull rt_mutex_futex_unlock() out from under hb->lock
> >   futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
> >   futex: Futex_unlock_pi() determinism
> >   futex,rt_mutex: Fix rt_mutex_cleanup_proxy_lock()
> > 
> > Thomas Gleixner (3):
> >   futex: Rename free_pi_state() to put_pi_state()
> >   rtmutex: Make wait_lock irq safe
> >   futex: Avoid freeing an active timer
> > 
> >  include/linux/rcupdate.h        |   4 +-
> >  kernel/futex.c                  | 245 +++++++++++++++++++++-----------
> >  kernel/locking/rtmutex.c        | 185 +++++++++++++-----------
> >  kernel/locking/rtmutex_common.h |   2 +-
> >  4 files changed, 262 insertions(+), 174 deletions(-)
> 
> 
> To all concerned,
> 
> I have verified that this series of patches, when applied
> to 4.4.277, passes the futex-unlock-pi replicator I posted
> to lkml on July 19.
> 
>   Subject: [BUG] 4.4.262: infinite loop in futex_unlock_pi (EAGAIN loop)
> 
> Acked-by: Joe Korty <joe.korty@concurrent-rt.com>
> 

Thanks for testing and the series, all now queued up.

I'll go do a -rc release with just this set of patches in it so that
people can test it well.

greg k-h

      reply	other threads:[~2021-08-08  6:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 13:46 [PATCH 4.4 00/11] Fix a potential infinite loop in RT futex-pi scenarios Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 01/11] futex: Rename free_pi_state() to put_pi_state() Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 02/11] futex: Cleanup refcounting Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 03/11] futex,rt_mutex: Introduce rt_mutex_init_waiter() Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 04/11] futex: Pull rt_mutex_futex_unlock() out from under hb->lock Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 05/11] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock() Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 06/11] futex: Futex_unlock_pi() determinism Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 07/11] rtmutex: Make wait_lock irq safe Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 08/11] futex: Handle transient "ownerless" rtmutex state correctly Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 09/11] futex: Avoid freeing an active timer Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 10/11] futex,rt_mutex: Fix rt_mutex_cleanup_proxy_lock() Zhen Lei
2021-08-02 13:46 ` [PATCH 4.4 11/11] rcu: Update documentation of rcu_read_unlock() Zhen Lei
2021-08-03  0:53 ` [PATCH 4.4 00/11] Fix a potential infinite loop in RT futex-pi scenarios Joe Korty
2021-08-08  6:46   ` Greg Kroah-Hartman [this message]

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=YQ990KMeDFspvGDQ@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=anna-maria@linutronix.de \
    --cc=efault@gmx.de \
    --cc=joe.korty@concurrent-rt.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sasha.levin@oracle.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thunder.leizhen@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.