From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19888 invoked by alias); 12 Mar 2015 18:26:08 -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 19872 invoked by uid 89); 12 Mar 2015 18:26:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f41.google.com Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Mar 2015 18:26:06 +0000 Received: by labhs14 with SMTP id hs14so17219728lab.5 for ; Thu, 12 Mar 2015 11:26:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sfYGHLFjo46fk1xVycuC+K32X19YeCZrmp24ZCv572k=; b=T0nOSajXSejqPszyUDDMzQoDkuVX8mQVAthjo76yKfH2QxanrxlWDi4Wh7j4pS3uMy 7cXCbJC7ta8Bpa4nmq3M4mZ13/upLPDr3v6uEEgUVcLDmSbpegvzTQXcGY9p5XkooDHK N08zZdjQHdj/KGgEa7f0olTKVIK2C5w6ToYQMcOtEkEyl5vqQnxkEHQYriFMj+WzI7Ke V0PNjGb5CNQrCqGyQQsHp7luA7P/V6HjZ65rsgK76l2NFEnFzPxSjrt0m+gCn/jRfSXV 1AaW1SmqQBCeV4JC1UsiZNuyXNIOtz9fCknDqkpaCaYWHfleDJUXx+f8gqyihkABuA1k 1oiA== X-Gm-Message-State: ALoCoQkyrZWXxXR9fR0zwNViZJbXOnmmXYTpwOuWaXkucw8xqQpR1kXGzm5Wfm1kJch6WHssx92m X-Received: by 10.152.26.136 with SMTP id l8mr40366881lag.109.1426184763238; Thu, 12 Mar 2015 11:26:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.232 with HTTP; Thu, 12 Mar 2015 11:25:43 -0700 (PDT) In-Reply-To: <5501D8CF.7020204@redhat.com> 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> <5501D8CF.7020204@redhat.com> From: Andy Lutomirski Date: Thu, 12 Mar 2015 18:26:00 -0000 Message-ID: Subject: Re: vvar, gup && coredump To: Pedro Alves Cc: Oleg Nesterov , Jan Kratochvil , Sergio Durigan Junior , GDB Patches , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-03/txt/msg00367.txt.bz2 On Thu, Mar 12, 2015 at 11:19 AM, Pedro Alves wrote: > 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. This is why we currently dump the vdso text. On arm64 (the only other architecture that uses a real vma for vvar data IIRC), we use a more normal vma and we dump it. x86 is the odd one out here. We could just leave the kernel alone. The data that gets dumped is of dubious value, but it could be slightly helpful when debugging vdso crashes*, but, of course, dumping it is inherently racy. * The vdso never crashes :) --Andy > > Thanks, > Pedro Alves > -- Andy Lutomirski AMA Capital Management, LLC