linux-kernel - Re: 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>] [day] [month] [year] [list]

Date:	Thu, 24 Oct 2013 10:13:56 +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: Re: [PATCH] futex: Remove the owner check when waking task in
 handle_futex_death



Zhang Yi <zhang.yi20@....com.cn> wrote on 2013/10/08 13:59:36:

> 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.

Are there any questions?

--
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/