From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52875 invoked by alias); 12 Mar 2015 17:40:56 -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 52857 invoked by uid 89); 12 Mar 2015 17:40:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 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 17:40:54 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CHenNI026923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 13:40:50 -0400 Received: from tranklukator.brq.redhat.com (dhcp-1-208.brq.redhat.com [10.34.1.208]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t2CHelmg019553; Thu, 12 Mar 2015 13:40:48 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Thu, 12 Mar 2015 18:39:03 +0100 (CET) Date: Thu, 12 Mar 2015 17:40:00 -0000 From: Oleg Nesterov To: Andy Lutomirski Cc: Jan Kratochvil , Sergio Durigan Junior , GDB Patches , Pedro Alves , "linux-kernel@vger.kernel.org" Subject: Re: vvar, gup && coredump Message-ID: <20150312173901.GA12225@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2015-03/txt/msg00357.txt.bz2 On 03/12, Andy Lutomirski wrote: > > On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov wrote: > > On 03/12, Andy Lutomirski wrote: > >> > > As for 32-bit applications. Yes, this can't work because 32-bit simply > > can't access this "high" memory. But you know, it would be very nice to > > have the fixmap-like "global" area in init_mm which is also visible to > > compat applications. If we had it, uprobes could work without xol vma's. > > > It could work for 32-bit native, but not for 32-bit compat. Yes, yes, I meant 32-bit compat apps. Once again, it would be nice if we had the "low" fixmaps in init_mm. But unlikely this is possible... > On a related note, I'm hoping to rework the mm part pretty heavily: > > http://lkml.kernel.org/r/cover.1414629045.git.luto@amacapital.net OK... not that I really understand this email. Well. Speaking of vdso. I understand that unlikely we can do this, but for uprobes it would be nice to have a anon-inode file behind this mapping, so that vma_interval_tree_foreach() could work, etc. OK, this is completely off-topic, please forget. And I noticed that I didn't read your previous email carefully enough... > That sounds reasonable to me. I'll write the patch later today. Sure, please send a patch if you want to do this. > gdb will still need changes, though, right? This is up to gdb developers. To me, it should simply skip this VM_DONTDUMP vma. Oleg.