Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1225915

RE: [PATCH v2] futex: lower the lock contention on the HB lock during wake up

Show all headers | View raw

> > I assume your pseudo code set_waiter_bit is mapped to the real code
> > "futex_lock_pi_atomic", It's possible for futex_lock_pi_atomic to
> > successfully set FUTEX_WAITERS bit, but return with Page fault, for
> > example, like fail in lookup_pi_state().
> 
> No. It's not. lookup_pi_state() cannot return EFAULT. The only function
> which can fault inside of lock_pi_update_atomic() is the actual cmpxchg.
> Though lock_pi_update_atomic() can successfully set the waiter bit and
> then return with some other failure code (ESRCH, EAGAIN, ...). But that
> does not matter at all.
> 
> Any failure return will end up in a retry. And if the waker managed to
> release the futex before the retry takes place then the waiter will see
> that and take the futex.
> 
Let me try to descript the application failure here.

The application is a multi-thread program, to use the pairs of mutex_lock and 
mutex_unlock to protect the shared data structure. The type of this mutex
is PTHREAD_MUTEX_PI_RECURSIVE_NP. After running long time, to say several days,
the mutex_lock data structure in user space looks like corrupt.

   thread 0 can do mutex_lock/unlock     
   __lock = this thread | FUTEX_WAITERS
   __owner = 0, should be this thread
   __counter keep increasing, although there is no recursive mutex_lock call.

   thread 1 will be stuck 

The primary debugging shows the content of __lock is wrong in first. After a call of
Mutex_unlock, the value of __lock should not be this thread self. But we observed
The value of __lock is still self after unlock. So, other threads will be stuck,
This thread could lock due to recursive type and __counter keep increasing, 
although mutex_unlock return fails, due to the wrong value of __owner, 
but the application did not check the return value. So the thread 0 looks
like fine. But thread 1 will be stuck forever.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Zhu Jefferry <Jefferry.Zhu@freescale.com> - 2015-09-15 04:10 +0200
  RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Thomas Gleixner <tglx@linutronix.de> - 2015-09-16 02:10 +0200
    RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Zhu Jefferry <Jefferry.Zhu@freescale.com> - 2015-09-16 02:20 +0200
      RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Thomas Gleixner <tglx@linutronix.de> - 2015-09-16 10:10 +0200
        RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Zhu Jefferry <Jefferry.Zhu@freescale.com> - 2015-09-16 12:10 +0200
          RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Thomas Gleixner <tglx@linutronix.de> - 2015-09-16 12:30 +0200
            RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Zhu Jefferry <Jefferry.Zhu@freescale.com> - 2015-09-16 13:20 +0200
              RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Thomas Gleixner <tglx@linutronix.de> - 2015-09-16 15:40 +0200
                RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Zhu Jefferry <Jefferry.Zhu@freescale.com> - 2015-09-17 02:00 +0200
                RE: [PATCH v2] futex: lower the lock contention on the HB lock during  wake up Thomas Gleixner <tglx@linutronix.de> - 2015-09-17 09:20 +0200

csiph-web