mbox series

[4.4,00/11] Fix a potential infinite loop in RT futex-pi scenarios

Message ID 20210802134624.1934-1-thunder.leizhen@huawei.com
Headers show
Series Fix a potential infinite loop in RT futex-pi scenarios | expand

Message

Leizhen (ThunderTown) Aug. 2, 2021, 1:46 p.m. UTC
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(-)

-- 
2.26.0.106.g9fadedd

Comments

Joe Korty Aug. 3, 2021, 12:53 a.m. UTC | #1
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>
Greg KH Aug. 8, 2021, 6:46 a.m. UTC | #2
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