From: Peter Zijlstra <peterz@infradead.org>
To: Jens Rosenboom <jens@mcbone.net>
Cc: Sonny Rao <sonnyrao@us.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: futexes: Still infinite loop in get_futex_key() in 2.6.31-rc4
Date: Mon, 27 Jul 2009 14:23:29 +0200 [thread overview]
Message-ID: <1248697409.6987.1617.camel@twins> (raw)
In-Reply-To: <1248697004.7279.31.camel@fnki-nb00130>
On Mon, 2009-07-27 at 14:16 +0200, Jens Rosenboom wrote:
> On Mon, 2009-07-27 at 13:31 +0200, Peter Zijlstra wrote:
> > On Mon, 2009-07-27 at 10:00 +0200, Jens Rosenboom wrote:
> > > We have a problem with infinitely running processes on kernels at least
> > > since 2.6.29.4. It happens on a loaded machine after running for a
> > > couple of days,
> >
> > What kinds of machine, i386? Could you please enable
> > CONFIG_FRAME_POINTER, these backtraces are quite mangled.
>
> i686 or AMD dualcore Opteron to be exact. CONFIG_FRAME_POINTER is
> enabled, the complete kernel-config is attached, maybe some other
> debugging options are needed? But I copied just the part pertaining to
> the stuck process, maybe the complete log has the parts you are missing?
Ah, weird. The question of course is, does an x86_64 kernel suffer the
same problem?
> > > that a "ps ax" seems to get stuck in get_futex_key while
> > > exiting. Sadly your patch
> >
> > Who's patch, and which patch? 7c8fa4f04ab956076605422d5ed37410893a8a73?
> > That was only regarding huge pages.
>
> Yes, that is the one I was talking about and the commit message seemed
> to match what I was seeing here.
Are you in fact using huge pages?
> > The only loop in get_futex_key() appears to be the one around
> > get_user_pages_fast(), and I'm not quite sure how that could get stuck
> > like this.
> >
> > Could it be glibc loops on futex_wake() returning -EFAULT?
>
> How would I be able to check that?
strace the struck process I think, you'd see tons of sys_futex() calls
with FUTEX_WAKE* returning -EFAULT.
next prev parent reply other threads:[~2009-07-27 12:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-27 8:00 Jens Rosenboom
2009-07-27 11:31 ` Peter Zijlstra
2009-07-27 12:16 ` Jens Rosenboom
2009-07-27 12:23 ` Peter Zijlstra [this message]
2009-07-27 12:45 ` Jens Rosenboom
2009-07-27 13:36 ` Peter Zijlstra
2009-07-27 13:41 ` Eric Dumazet
2009-07-27 14:00 ` Jens Rosenboom
2009-07-27 16:00 ` Ray Lee
2009-07-29 6:22 ` Jens Rosenboom
2009-07-29 9:57 ` Jens Rosenboom
2009-07-29 10:01 ` Peter Zijlstra
2009-07-29 10:26 ` Eric Dumazet
2009-07-29 10:56 ` Eric Dumazet
2009-07-29 14:29 ` Jens Rosenboom
2009-07-30 14:13 ` Jens Rosenboom
2009-07-31 10:00 ` [ PATCH] execve: must clear current->clear_child_tid Eric Dumazet
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=1248697409.6987.1617.camel@twins \
--to=peterz@infradead.org \
--cc=jens@mcbone.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sonnyrao@us.ibm.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®