[lkml]   [2009]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel BUG at fs/ext/super.c:428
Peter Zijlstra wrote:
> On Wed, 2009-01-21 at 12:10 -0800, Pallipadi, Venkatesh wrote:
>> On Wed, 2009-01-14 at 13:20 -0800, Theodore Tso wrote:
>>> On Wed, Jan 14, 2009 at 08:29:37PM +0100, Peter Zijlstra wrote:
>>>>> 38d47c1b7075bd7ec3881141bb3629da58f88dab is first bad commit
>>>>> commit 38d47c1b7075bd7ec3881141bb3629da58f88dab
>>>>> Author: Peter Zijlstra <>
>>>>> Date: Fri Sep 26 19:32:20 2008 +0200
>>>>> futex: rely on get_user_pages() for shared futexes
>>>>> On the way of getting rid of the mmap_sem requirement for shared futexes,
>>>>> start by relying on get_user_pages().
>>>>> Signed-off-by: Peter Zijlstra <>
>>>>> Acked-by: Nick Piggin <>
>>>>> Signed-off-by: Ingo Molnar <>
>>>> However does a futex change make ext3 crap its pants?
>>> I agree, this doesn't make much sense. I've looked at the patch, and
>>> I don't see how this would cause an ext3 orphaned-inode list handling
>>> problem
>>> Are you sure the bisect was done correctly? Have you tried reverting
>>> that one commit, or otherwise conclusively shown that a kernel with
>>> this commit fails, and one without this commit works just fine?
>> Unfortunately, I cannot revert this patch alone from upstream git.
>> But I consistently see
>> upstream git: Always produces this oops on reboot
>> checkout of 38d47c1b: Always produces this oops on reboot
>> checkout of 94aca1da (one patch before the above commit): Reboots fine
>> without the oops.
>> This is petty specific to the particular userspace, looks like.
>> I only see this on SLES10 installation. Also, I need a non-root user
>> logged in at least once after boot through X to see this problem. I was
>> always seeing this as I had autologin on local terminal and was remotely
>> rebooting the system. If I just boot to init 3 or boot to init 5 with no
>> user logged in or boot to init 5 with root logged in, I do not see this
>> problem.
> Ted, could this happen due an extra iput()?
> In that case, Venki, does the below patch fix it?
> Credit goes to Darren for spotting this.
> ---
> kernel/futex.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> diff --git a/kernel/futex.c b/kernel/futex.c
> index f89d373..f4132ab 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -929,7 +929,7 @@ out_unlock:
> /* drop_futex_key_refs() must be called outside the spinlocks. */
> while (--drop_count >= 0)
> - drop_futex_key_refs(&key1);
> + drop_futex_key_refs(&key2);

Unfortunately, I realized later that this code was indeed correct and I
asked Ingo to pull my patch implementing the above change. Quoting my
previous mail on the subject:

"I believe what is happening here is that the requeue loop requeues each
waiter from one futex (key1) to another (key2). It rightly takes a
reference to the futex at key2 and then decrements the references to
key1 by drop_count (since the waiters now reference key2, not key1).
The newly taken key2 references will be dropped in futex_wait() when
each waiter is woken up and takes the futex."

However, there are still two patches in linux-tip/core/futexes that
addresses get|put symmetry of futex keys:


However, the first is an addition of a WARN_ON (which is unlikely to
catch this issue as it was geared toward catching puts on failed gets).
The latter mostly adds puts where they were missing, so also unlikely
to help.


> out_put_keys:
> put_futex_key(fshared, &key2);

Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-01-26 17:41    [W:0.034 / U:12.352 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site