From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57602 invoked by alias); 18 Mar 2015 01:45:09 -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 57580 invoked by uid 89); 18 Mar 2015 01:45:03 -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-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; Wed, 18 Mar 2015 01:45:02 +0000 Received: by lagg8 with SMTP id g8so24091549lag.1 for ; Tue, 17 Mar 2015 18:44:58 -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=Ig8LmPFxMagNNZCSPecdNQVpG9gKj7eSfRRqQ46o0Ks=; b=JfSaMh3bJNtDTpFmbYXgrNW5+56Hgjr5XbJFLYH4RFmQhWkyaDotLYQeE9A5bNbnHM B72Q3BEZh6sQ1p6o6oXGSY+ZAPNejVXUz/MoFqDw4LaArIYtlvYXu++kk+XWUUehEJSu i+QBcdP6XCD6RiwuNfpRyVkofUPkCkL20NzO00563+TeDigkvfh1tFK5McW52IA/Yfv4 glyFygBQST6JzvaSHjzW1D7hUJ2jSB7ocyp2f2rrhvxdeOTsldaftkADtmbOMRft8gn9 Zub20EtCHYiKErMb7ldAIKQ/fLUl1Ga1m63Dlhe/xxO6UncSt12JM7S6bkyANMKlr+vc 2fBQ== X-Gm-Message-State: ALoCoQkMmkwf05mS/cPmo4KUXSk9vR3l0U+O043K3GSqdFSsTjpPkjfPjlQ7LGcomsx38PIK1/Ma X-Received: by 10.112.89.71 with SMTP id bm7mr34741656lbb.20.1426643098859; Tue, 17 Mar 2015 18:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.232 with HTTP; Tue, 17 Mar 2015 18:44:37 -0700 (PDT) In-Reply-To: <20150317134309.GA365@redhat.com> References: <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> <20150311200052.GA22654@redhat.com> <20150312143438.GA4338@redhat.com> <20150312165423.GA10073@redhat.com> <20150312174653.GA13086@redhat.com> <20150316190154.GA18472@redhat.com> <20150316194446.GA21791@redhat.com> <20150317134309.GA365@redhat.com> From: Andy Lutomirski Date: Wed, 18 Mar 2015 01:45:00 -0000 Message-ID: Subject: Re: install_special_mapping && vm_pgoff (Was: vvar, gup && coredump) To: Oleg Nesterov Cc: Hugh Dickins , Linus Torvalds , Jan Kratochvil , Sergio Durigan Junior , GDB Patches , Pedro Alves , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-03/txt/msg00532.txt.bz2 On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov wrote: > On 03/16, Oleg Nesterov wrote: >> >> On 03/16, Andy Lutomirski wrote: >> > >> > Ick, you're probably right. For what it's worth, the vdso *seems* to >> > be okay (on 64-bit only, and only if you don't poke at it too hard) if >> > you mremap it in one piece. CRIU does that. >> >> I need to run away till tomorrow, but looking at this code even if "one piece" >> case doesn't look right if it was cow'ed. I'll verify tomorrow. > > And I am still not sure this all is 100% correct, but I got lost in this code. > Probably this is fine... > > But at least the bug exposed by the test-case looks clear: > > do_linear_fault: > > vmf->pgoff = (((address & PAGE_MASK) - vma->vm_start) >> PAGE_SHIFT) > + vma->vm_pgoff; > ... > > special_mapping_fault: > > pgoff = vmf->pgoff - vma->vm_pgoff; > > > So special_mapping_fault() can only work if this mapping starts from the > first page in ->pages[]. > > So perhaps we need _something like_ the (wrong/incomplete) patch below... > > Or, really, perhaps we can create vdso_mapping ? So that map_vdso() could > simply mmap the anon_inode file... That's slightly tricky, I think, because it could start showing up in /proc/PID/map_files or whatever it's called, and I don't think we want that. I also don't want to commit to all special mappings everywhere being semantically identical (there are already two kinds on both x86 and arm64, and I'd eventually like to have them vary per-process as well). None of that precludes using non-null vm_file, but it's a complication. Your patch does look like a considerable improvement, though. Let me see if I can find some time to fold it in with the rest of my special mapping rework over the next few days. --Andy > > Oleg. > > --- x/mm/mmap.c > +++ x/mm/mmap.c > @@ -2832,6 +2832,8 @@ int insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma) > return 0; > } > > +bool is_special_vma(struct vm_area_struct *vma); > + > /* > * Copy the vma structure to a new location in the same mm, > * prior to moving page table entries, to effect an mremap move. > @@ -2851,7 +2853,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, > * If anonymous vma has not yet been faulted, update new pgoff > * to match new location, to increase its chance of merging. > */ > - if (unlikely(!vma->vm_file && !vma->anon_vma)) { > + if (unlikely(!vma->vm_file && !is_special_vma(vma) && !vma->anon_vma)) { > pgoff = addr >> PAGE_SHIFT; > faulted_in_anon_vma = false; > } > @@ -2953,6 +2955,11 @@ static const struct vm_operations_struct legacy_special_mapping_vmops = { > .fault = special_mapping_fault, > }; > > +bool is_special_vma(struct vm_area_struct *vma) > +{ > + return vma->vm_ops == &special_mapping_vmops; > +} > + > static int special_mapping_fault(struct vm_area_struct *vma, > struct vm_fault *vmf) > { > @@ -2965,7 +2972,7 @@ static int special_mapping_fault(struct vm_area_struct *vma, > * We are allowed to do this because we are the mm; do not copy > * this code into drivers! > */ > - pgoff = vmf->pgoff - vma->vm_pgoff; > + pgoff = vmf->pgoff; > > if (vma->vm_ops == &legacy_special_mapping_vmops) > pages = vma->vm_private_data; > @@ -3014,6 +3021,7 @@ static struct vm_area_struct *__install_special_mapping( > if (ret) > goto out; > > + vma->vm_pgoff = 0; > mm->total_vm += len >> PAGE_SHIFT; > > perf_event_mmap(vma); > -- Andy Lutomirski AMA Capital Management, LLC