[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwooh31=GMVUoriev+t92=roye_ck+czqr48M1sQ3UOMg@mail.gmail.com>
Date: Mon, 1 Dec 2014 09:53:16 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Will Deacon <will.deacon@....com>, Tejun Heo <tj@...nel.org>
Cc: Dave Jones <davej@...hat.com>,
Andy Lutomirski <luto@...capital.net>,
Don Zickus <dzickus@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: frequent lockups in 3.18rc4
On Mon, Dec 1, 2014 at 9:10 AM, Will Deacon <will.deacon@....com> wrote:
>
> So I don't even have binfmt-misc compiled in. The two handlers I have are
> BINFMT_ELF and BINFMT_SCRIPT, but they both check for headers that we won't
> get back from oom_score afaict.
Hmm. So I can't even get that "oom_score" file to be executable in the
first place, which should mean that execve() should terminate very
quickly with an EACCES error.
The fact that you have a "flush_work()" that is waiting for completion
is interesting. Maybe the odd new thread is a worker thread for some
modprobe or similar, and we . There's that whole
request_module("binfmt-%04x", *(ushort *)(bprm->buf + 2))
which ends up creating a new work. Maybe the flush_work() is waiting
for that whole mess. Adding Tejun to the cc, since there *were*
changes to workqueues etc since 3.16..
Tejun, full thread on lkml, I'm assuming you can find it in your mail archives..
Linus
--
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/
Powered by blists - more mailing lists