From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755261AbbCLSEZ (ORCPT <rfc822;w@1wt.eu>);
	Thu, 12 Mar 2015 14:04:25 -0400
Received: from mx1.redhat.com ([209.132.183.28]:24672 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755079AbbCLSEY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 12 Mar 2015 14:04:24 -0400
Date: Thu, 12 Mar 2015 19:02:29 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
        Jan Kratochvil <jan.kratochvil@redhat.com>,
        GDB Patches <gdb-patches@sourceware.org>,
        Pedro Alves <palves@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: vvar, gup && coredump
Message-ID: <20150312180229.GA13711@redhat.com>
References: <20150305154827.GA9441@host1.jankratochvil.net> <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> <20150311200052.GA22654@redhat.com> <20150312143438.GA4338@redhat.com> <CALCETrW5rmAHutzm_OwK2LTd_J0XByV3pvWGyW=AmC=v7rLfhQ@mail.gmail.com> <20150312165423.GA10073@redhat.com> <CALCETrUGu5Wc7BbbQ4_tn29JGbyotUJay67EHBEgSa8-bz01Jg@mail.gmail.com> <20150312173901.GA12225@redhat.com> <874mpqp0sm.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <874mpqp0sm.fsf@redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/12, Sergio Durigan Junior wrote:
>
> On Thursday, March 12 2015, Oleg Nesterov wrote:
>
> >> gdb will still need changes, though, right?
> >
> > This is up to gdb developers. To me, it should simply skip this
> > VM_DONTDUMP vma.
>
> If I understood this discussion correctly (and thanks Andy and Oleg for,
> *ahem*, dumping all this useful information for us!), GDB will not need
> modifications in the Linux kernel in this area.  In fact, my patch
> already implements the "ignore VM_DONTDUMP mappings" part, so we're
> pretty much covered.

OK, thanks.

And it seems that we all agree that the kernel should not dump this vma
too. Could you confirm that this is fine from gdb pov just in case?


However. Even if we do not want it in the coredump, this can confuse gdb
users which might want to read this memory during debugging. So perhaps
we still can add ->access() to "fix" PTRACE_PEEK/access_remote_vm later.

But I see another email from Andy, so lets forget about this for now.

Oleg.