From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26332 invoked by alias); 12 Mar 2015 17:18:24 -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 26319 invoked by uid 89); 12 Mar 2015 17:18:23 -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-la0-f54.google.com Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Mar 2015 17:18:21 +0000 Received: by labmn12 with SMTP id mn12so17424914lab.0 for ; Thu, 12 Mar 2015 10:18:18 -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=3LbjluL1CzUvL05IPShsqJa9hKFDttPNKRlxHbUFknY=; b=drDmYepJG6A8P/fF4+6FX9KLNfz7tQl72kiKy5ed1YbN4HoXupLQjKuFQ9M7lFO0yT vtV85hGMkcAseHw5HPlvSh+gVrqz225noiovAbKz1MwWQOppWnOueifkVvjKDFqpPjTN m9OWsdf6nMGAFlBFU0yUjYMyOzn8QazxR6v5qonM1dW08nu2H7hSJjpZYRXH50Aq7416 A+sEeKd2sSOsF+cnYpmZWwdK79AFQGnDNCLTohd5F7arH9jLDGcYr8NakqpxLDCnIetj YhQgMYOSGgYsRjRUnLT4tKU/YrrQrhbhVlVZenHrlA3tBUpGn5ixBSN3XHNCcKd/FcAZ uonQ== X-Gm-Message-State: ALoCoQkrkYgocNyx9wnisnYDZP1FtIIDbpClylgsr9SprwBTvlWQvE/ngY50y01B7MW77rp1KzME X-Received: by 10.152.10.66 with SMTP id g2mr39875762lab.44.1426180698556; Thu, 12 Mar 2015 10:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.232 with HTTP; Thu, 12 Mar 2015 10:17:58 -0700 (PDT) In-Reply-To: <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> <20150312165423.GA10073@redhat.com> From: Andy Lutomirski Date: Thu, 12 Mar 2015 17:18: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/msg00354.txt.bz2 On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov wrote: > 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. > It could work for 32-bit native, but not for 32-bit compat. Also, I have grand plans to add per-task vvar overrides for seccomp and such. And RIP-relative addressing is a bit nicer than absolute :) It used to work that way, but we changed it in 3.15 IIRC. 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 --Andy > Oleg. > -- Andy Lutomirski AMA Capital Management, LLC