From: Darren Hart <dvhart@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: xby <scxby@163.com>,
linux-kernel@vger.kernel.org,
"xie.baoyou172958@zte.com.cn" <xie.baoyou172958@zte.com.cn>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: PROBLEM:a bug about pi-futex maybe let the program going to hang
Date: Mon, 28 Mar 2011 15:13:27 -0700 [thread overview]
Message-ID: <4D910807.1050601@linux.intel.com> (raw)
In-Reply-To: <1301300782.4859.7.camel@twins>
On 03/28/2011 01:26 AM, Peter Zijlstra wrote:
> On Mon, 2011-03-28 at 15:25 +0800, xby wrote:
>> hi, all.
>
> Works better if you also CC people who actually work on that code.
>
>> Maybe, there is a bug about pi-futex, it would let the program in user-space going to hang.
>>
>> We have a board: CPU is powerpc 8572, two core. after ran one month, the state of pi-futex in user-space got bad: mutex->__data.__lock is 0x8000023e, mutex->__data.__count is 0, mutex->__data.__owner is 0.
>>
>> then, I review file "kernel/funtex.c"(the version is linux 2.6.38), found a case:
>>
>> if there are 3 thread, named threadA, threadB, threadC。thread A hold mutexM, threadB and threadC is waiting mutexM. They run as fllow steps:
>>
>> 1. threadB and threadC sleep at line 1984.
>> 2. threadB receive a signal, then it will be wake up.
>> 3. threadA unlock mutexM, and give mutexM to threadB.
>> 4. threadB call fixup_owner, try to give mutex to threadC.
>> 5. at line 1580, threadB trigger a addr-fault, then goto handle_fault.
>> 6. at line 1617, threadB release spinlock, then handle fault.
>> 7. threadC got spinlock, and call fixup_owner, and got mutexM.
>> 8. threadC give mutexM to threadB.
>> 9. threadB re-got spinlock, it will found "pi_state->owner == oldowner" and retry to fixup.
>> 10. threadB give mutexM to threadC, that's a bad thing.
>>
>> we have wrote a program, this program can prove all above.
>
> It would have been ever so much more useful if you'd have included that.
Please reply with the testcase and your glibc version please. If this is
a custom kernel, please make your .config as well.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-03-28 22:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 7:25 PROBLEM:a bug about pi-futex maybe let the program going to hang xby
2011-03-28 8:26 ` Peter Zijlstra
2011-03-28 9:43 ` xby
2011-03-28 17:37 ` Steven Rostedt
2011-03-28 22:13 ` Darren Hart [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-03-26 4:19 scxby
2011-03-28 17:16 ` Steven Rostedt
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=4D910807.1050601@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=scxby@163.com \
--cc=tglx@linutronix.de \
--cc=xie.baoyou172958@zte.com.cn \
/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.