[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101214202920.6835a3c2@suzukikp>
Date: Tue, 14 Dec 2010 20:29:20 +0530
From: "Suzuki K. Poulose" <suzuki@...ibm.com>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: linux-kernel@...r.kernel.org,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
Christoph Hellwig <hch@....de>,
Masami Hiramatsu <mhiramat@...hat.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Daisuke HATAYAMA <d.hatayama@...fujitsu.com>,
Andi Kleen <andi@...stfloor.org>,
Roland McGrath <roland@...hat.com>,
Amerigo Wang <amwang@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] [Patch 0/21] Non disruptive application core dump
infrastructure
On Tue, 14 Dec 2010 12:54:05 +0200
Alexey Dobriyan <adobriyan@...il.com> wrote:
> On Tue, Dec 14, 2010 at 03:22:59PM +0530, Suzuki K. Poulose wrote:
> > The interface is provided by a /proc/pid/core file, reading which can give the
>
> What happens when process opens /proc/self/core ?
The current thread will be skipped for freeze(), and all the others will be
frozen.We fill in the register states with 0's for the active threads.
> What happens when process opens /proc/self/core and coredumps before close(2).
Thanks for pointing this out. With the current code, this causes a hang for the
current process, waiting for the other threads to clear. I will think about
a solution to this making use of the mm->core_state information.
Thanks a lot for the review.
Suzuki
--
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