From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87177 invoked by alias); 12 Mar 2015 17:56:13 -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 87163 invoked by uid 89); 12 Mar 2015 17:56:12 -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-f47.google.com Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Mar 2015 17:56:11 +0000 Received: by labmn12 with SMTP id mn12so17657044lab.0 for ; Thu, 12 Mar 2015 10:56:07 -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=1xfTG2GUH2WwDXFE0lwW51RcT1ATkIbD8viHM3gzkQA=; b=Nj/FV1s2niK08i1yWOUbmc4DJj0SERQrgu+Am/acrVUcOU24f5hz8xxRDsRt4/P/XN sD4AQXnJnhsJCFA9bMnwGye2kIr7mc9Oi5EbFTSEQz9l5zJ8Vf7MCVpiSnM/KqpPZ+JV MaObWJqM9rBaaO5YriLmgKfK7asMuCOKv2XibfKTUKLjBSH5c/EIQx5E0vK9OOUotffg 0pB6BnZ7tzF7AtTjvl0rEghoplCCrT2McGy8FJrqvOc9M+M1PPhRcm5IXHmiUEoGzIQs aV5Jzx9+igUcMJEhQL3ytfCgpFsxixb298d1VC7GFnAbH3u0MmTKTDk6+3ZeHZJHhtGC Fb6g== X-Gm-Message-State: ALoCoQlzcqhg65NORX/F0G5deB5Ju3qb1V4kvbHvKdP0U7XRt31FM2+Gk90yjSYzg1+Y+lLy8m5x X-Received: by 10.112.161.229 with SMTP id xv5mr15007904lbb.6.1426182967808; Thu, 12 Mar 2015 10:56:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.232 with HTTP; Thu, 12 Mar 2015 10:55:46 -0700 (PDT) In-Reply-To: <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> <20150312173901.GA12225@redhat.com> From: Andy Lutomirski Date: Thu, 12 Mar 2015 17:56: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/msg00362.txt.bz2 On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov wrote: > 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. Couldn't you do that directly in the uprobes code? That is, create an anon_inode file and just map it the old-fashioned way? --Andy > > > > 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. > -- Andy Lutomirski AMA Capital Management, LLC