From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030222AbbCLQ4W (ORCPT ); Thu, 12 Mar 2015 12:56:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40460 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932409AbbCLQ4Q (ORCPT ); Thu, 12 Mar 2015 12:56:16 -0400 Date: Thu, 12 Mar 2015 17:54:23 +0100 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) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.