From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2011 12:31:45 +0100 (CET) Received: from h5.dl5rb.org.uk ([81.2.74.5]:54017 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S1903946Ab1KBLbh (ORCPT ); Wed, 2 Nov 2011 12:31:37 +0100 Received: from duck.linux-mips.net (duck.linux-mips.net [127.0.0.1]) by duck.linux-mips.net (8.14.4/8.14.4) with ESMTP id pA2BUa1D014989; Wed, 2 Nov 2011 11:30:36 GMT Received: (from ralf@localhost) by duck.linux-mips.net (8.14.4/8.14.4/Submit) id pA2BUV0T014982; Wed, 2 Nov 2011 11:30:31 GMT Date: Wed, 2 Nov 2011 11:30:31 +0000 From: Ralf Baechle To: trisha yad Cc: Oleg Nesterov , linux-mm , Russell King - ARM Linux , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz, rientjes@google.com, Andrew Morton , Konstantin Khlebnikov , KOSAKI Motohiro , "Rafael J. Wysocki" , Rusty Russell , Tejun Heo Subject: Re: Issue with core dump Message-ID: <20111102113030.GE22462@linux-mips.org> References: <20111101152320.GA30466@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-archive-position: 31360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Return-Path: X-Keywords: X-UID: 1175 On Wed, Nov 02, 2011 at 12:03:39PM +0530, trisha yad wrote: > Thanks all for your answer. > > In loaded embedded system the time at with code hit do_user_fault() > and core_dump_wait() is bit > high, I check on my system it took 2.7 sec. so it is very much > possible that core dump is not correct. > It contain global value updated. > > So is it possible at time of send_signal() we can stop modification of > faulty thread memory ? On existing hardware it is impossible to take a consistent snapshot of a multi-threaded application at the time of one thread faulting. A software simulator can handle this sort of race condition but of course this approach has other disadvantages. Ralf From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 1717A6B0069 for ; Wed, 2 Nov 2011 07:30:56 -0400 (EDT) Date: Wed, 2 Nov 2011 11:30:31 +0000 From: Ralf Baechle Subject: Re: Issue with core dump Message-ID: <20111102113030.GE22462@linux-mips.org> References: <20111101152320.GA30466@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: trisha yad Cc: Oleg Nesterov , linux-mm , Russell King - ARM Linux , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz, rientjes@google.com, Andrew Morton , Konstantin Khlebnikov , KOSAKI Motohiro , "Rafael J. Wysocki" , Rusty Russell , Tejun Heo On Wed, Nov 02, 2011 at 12:03:39PM +0530, trisha yad wrote: > Thanks all for your answer. > > In loaded embedded system the time at with code hit do_user_fault() > and core_dump_wait() is bit > high, I check on my system it took 2.7 sec. so it is very much > possible that core dump is not correct. > It contain global value updated. > > So is it possible at time of send_signal() we can stop modification of > faulty thread memory ? On existing hardware it is impossible to take a consistent snapshot of a multi-threaded application at the time of one thread faulting. A software simulator can handle this sort of race condition but of course this approach has other disadvantages. Ralf -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org