From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62451 invoked by alias); 12 Mar 2015 16:56:16 -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 62441 invoked by uid 89); 12 Mar 2015 16:56:16 -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 16:56:15 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CGuCT1031071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 12:56:12 -0400 Received: from tranklukator.brq.redhat.com (dhcp-1-208.brq.redhat.com [10.34.1.208]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t2CGuAau002919; Thu, 12 Mar 2015 12:56:10 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Thu, 12 Mar 2015 17:54:26 +0100 (CET) Date: Thu, 12 Mar 2015 16:56: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: <20150312165423.GA10073@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> 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/msg00350.txt.bz2 On 03/12, Andy Lutomirski wrote: > > On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov wrote: > > > > 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. Of course, but this looks simple... is_cow_mapping() == F so FOLL_FORCE won't work anyway? > - 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. Yes, this is true. OK, lets not dump it. I'll probably send a patch which changes vma_dump_size() to check VM_DONTDUMP first... But this leads to another question: why do we want to expose this "vvar" vma at all? For the moment, forget about compat 32-bit applications running under 64-bit kernel. Can't we simply add FIX_VVAR_PAGE into fixed_addresses{}, map it into init_mm via set_fixmap(FIX_VVAR_PAGE, __PAGE_USER) and change __vdso.* functions to use fix_to_virt() address? I don't really understand the low-level details, I'd like to understand if this can work or not. And if it can work, why this is undesirable. 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. Oleg.