From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114218 invoked by alias); 12 Mar 2015 16:29:58 -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 114194 invoked by uid 89); 12 Mar 2015 16:29:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f174.google.com Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Mar 2015 16:29:55 +0000 Received: by lbdu14 with SMTP id u14so17235386lbd.0 for ; Thu, 12 Mar 2015 09:29:51 -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=5m4dUZHRgeHlOL2inT9Qf7HzAtgkACE4d6n3wd3s4Yc=; b=R2r/luiS57YOROMtIJ6Obquwk4EDmNzVXpYbwrt08aE8JLYt0BVO5cX8Id9jKsFTLa cHXOCmOIXmCEHsJB26ufLMXKUCxO+Q814kDcIdA8m5k7DgSaLG3CrEuWaPy7LB4eIjgc Ldl604DF1+ddu4q6003igjmVNpiY3o5jL0mOb20y9FAl/KuIFCQ2UkGQss0Yr5fkfv3n +5dkPFZCtcWzVmFkfd93WOpi15S2fJXNEv6/bRuyMFt3hyK2czfJQMa2Z9GvdqMfA9Uj EXJaUM2hamOoEv24F2GwM1laYdUQbZ/f2p3ConClD16AHsdjytqeEvtJODOzVi2FptPg c99w== X-Gm-Message-State: ALoCoQkzG44C79nJmyMgTcadqqTAg4TOcsh9SzusXOFCwN8I0zGVCdtJErNae2K4sSxfpKhYpdM8 X-Received: by 10.152.44.137 with SMTP id e9mr39275343lam.87.1426177791647; Thu, 12 Mar 2015 09:29:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.232 with HTTP; Thu, 12 Mar 2015 09:29:31 -0700 (PDT) In-Reply-To: <20150312143438.GA4338@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> From: Andy Lutomirski Date: Thu, 12 Mar 2015 16:29:00 -0000 Message-ID: Subject: Re: vvar, gup && coredump To: Oleg Nesterov Cc: Jan Kratochvil , Sergio Durigan Junior , GDB Patches , Pedro Alves , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-03/txt/msg00349.txt.bz2 On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov wrote: > Add cc's, change subject. > > On 03/11, Oleg Nesterov wrote: >> >> On 03/05, Jan Kratochvil wrote: >> > >> > On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote: >> > > On Thursday, March 05 2015, Jan Kratochvil wrote: >> > > > On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote: >> > > > Currently it also tries to dump [vvar] (by default rules) but that is >> > > > unreadable for some reason, causing: >> > > > warning: Memory read failed for corefile section, 8192 bytes at 0x7ffff6ceb000. >> > > > ^^^^^^^^^^^^^^ >> >> > It would be good to get a reply from a kernel aware person what does it mean >> > before such patch gets accepted. It can be also just a Linux kernel bug. >> >> _So far_ this doesn't look like a kernel bug to me. >> >> But! I need to recheck. In fact, it seems to me that I should discuss >> this on lkml. I have some concerns, but most probably this is only my >> misunderstanding, I need to read this (new to me) code more carefully. > > Hi Andy, we need your help ;) > > So, the problem is that gdb can't access the "vvar" mapping which looks > like the "normal" vma from user-space pov. > > Technically this is clear. vvar_mapping->pages is the "dummy" no_pages[] > array, get_user_pages() can't succeed. In fact even follow_page() can't > work because of VM_PFNMAP/_PAGE_SPECIAL set by remap_pfn_range(). > > What is not clear: do we really want gup() to fail? Or it is not trivial > to turn __vvar_page into the "normal" page? (to simplify the discussion, > lets ignore hpet mapping for now). We could presumably fiddle with the vma to allow get_user_pages to work on at least the first vvar page. There are some decently large caveats, though: - We don't want to COW it. If someone pokes at that page with ptrace, for example, and it gets COWed, everything will stop working because the offending process will no longer see updates. That way lies infinite loops. - The implementation could be odd. The vma is either VM_MIXEDMAP or VM_PFNMAP, and I don't see any practical way to change that. - The HPET and perhaps pvclock stuff. The HPET probably doesn't have a struct page at all, so you can't possibly get_user_pages it. > > Because this doesn't look consistent. gdb tries to "coredump" the live > process like the kernel does, but fails to dump the "r--p ... [vvar]" > region. > > > OK, gdb can look at VM_DONTDUMP bit in "VmFlags:" field in /proc/pid/smaps > and skip this vma. But, why (afaics) the kernel dumps this vma then? Lets > look at vma_dump_size(), > > /* always dump the vdso and vsyscall sections */ > if (always_dump_vma(vma)) > goto whole; > > if (vma->vm_flags & VM_DONTDUMP) > return 0; > > so the kernel ignores VM_DONTDUMP in this case, always_dump_vma() returns > true because of special_mapping_name(). Perhaps we should check VM_DONTDUMP > before always_dump_vma() ? > That sounds reasonable to me. I'll write the patch later today. gdb will still need changes, though, right? --Andy > > Or. We can teach gdb to read and dump its own "vvar" mapping to mimic the > kernel behaviour, this is the same read-only memory. But this hack doesn't > look nice, gdb should not know "too much" about the kernel internals. > > Oleg. > -- Andy Lutomirski AMA Capital Management, LLC