linux-kernel - Re: Re: Re: [PATCH] futex: Remove the owner check when waking task in handle_futex

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]

Date:	Tue, 8 Oct 2013 13:59:36 +0800
From:	zhang.yi20@....com.cn
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Re: Re: [PATCH] futex: Remove the owner check when waking task in
 handle_futex_death



Darren Hart <dvhart@...ux.intel.com> wrote on 2013/09/27 23:32:27:

>
> Re: Re: [PATCH] futex: Remove the owner check when waking task in handle_futex_death
>
> >
> > The earlier patch cannot solve another problem:
> > The owner wakes the next waiter through normal unlocking which make the
> > futex value as zero, the waked task exits before actually locking the mutex.
> > In this case, the owner doesn't call handle_futex_death() and the waked task
> > doesn't call futex_wake() when they are dying. The rest waiters will still
> > block as the same.
> >
> > This is also the reason that I drop the owner and FUTEX_WAITERS check,
> > because the futex value can be zero at that time.
> >
>
> If the FUTEX_WAITERS bit is not set, there are no waiters, and thus no
> need to wake. I understand why you dropped the OWNER check, but I'm not
> following this one. Where would the futex word be set from having
> waiters to zero when there might still be waiters pending?
>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
>

I have drawn a diagram as below:

               process1                     |      process2
   -------------------------------------------------------------
  |       thread1       |      thread2      |      thread3
   -------------------------------------------------------------
t1|pthread_mutex_lock:  |                   |
  |  __lock=self        |                   |
  |                     |                   |
t2|                     |pthread_mutex_lock:|
  |                     |__lock|=FUTEX_WAITERS
  |                     | syscall futex_wait|
  |                     |                   |
t3|                     |                   |pthrea_mutex_lock:
  |                     |                   |__lock|=FUTEX_WAITERS
  |                     |                   | syscall futex_wait
  |                     |                   |
t4|pthread_mutex_unlock:|                   |
  |  __lock=0           |                   |
  |  syscall futex_wake | waked             |
  |                     |                   |
t5| exit                |exit:              |
  |                     | handle_futex_death|
---------------------------------------------------------------
t6|                     |pthread_mutex_lock:|
  |                     |__lock=self|FUTEX_WAITERS


1, At time t4, in the unlocking process of glibc, it clears the FUTEX_WAITERS bit before
calling futex_wake syscall.

2, At time t5, thread2 cannot know if the FUTEX_WAITERS bit was set.

3, Time t6 is expected but can never be true.

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