From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4498 invoked by alias); 12 Mar 2015 18:20:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4485 invoked by uid 89); 12 Mar 2015 18:20:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Mar 2015 18:20:05 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CIK2Nq020964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 14:20:02 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2CIK0oD022515; Thu, 12 Mar 2015 14:20:00 -0400 Message-ID: <5501D8CF.7020204@redhat.com> Date: Thu, 12 Mar 2015 18:20:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Oleg Nesterov , Andy Lutomirski CC: Jan Kratochvil , Sergio Durigan Junior , GDB Patches , "linux-kernel@vger.kernel.org" Subject: Re: vvar, gup && coredump References: <878ufc9kau.fsf@redhat.com> <20150305154827.GA9441@host1.jankratochvil.net> <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> <20150311200052.GA22654@redhat.com> <20150312143438.GA4338@redhat.com> <20150312165423.GA10073@redhat.com> <20150312174653.GA13086@redhat.com> In-Reply-To: <20150312174653.GA13086@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00365.txt.bz2 On 03/12/2015 05:46 PM, Oleg Nesterov wrote: > On 03/12, Oleg Nesterov wrote: >> >> Yes, this is true. OK, lets not dump it. > > OTOH. We can probably add ->access() into special_mapping_vmops, this > way __access_remote_vm() could work even if gup() fails ? > > Jan, Sergio. How much do we want do dump this area ? The change above > should be justified. Memory mappings that weren't touched since they were initially mapped can be retrieved from the program binary and the shared libraries, even if the core dump is moved to another machine. However, in vvar case, sounds like there's nowhere to read it from offline? In that case, it could be justified to dump it. Thanks, Pedro Alves