From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB788C433E0 for ; Tue, 16 Mar 2021 20:17:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F4C564EBD for ; Tue, 16 Mar 2021 20:17:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F4C564EBD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 213C36B0036; Tue, 16 Mar 2021 16:17:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19E116B006C; Tue, 16 Mar 2021 16:17:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0AA56B006E; Tue, 16 Mar 2021 16:17:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id D0C646B0036 for ; Tue, 16 Mar 2021 16:17:39 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4E6DD8122 for ; Tue, 16 Mar 2021 20:17:39 +0000 (UTC) X-FDA: 77926847838.07.74FFB6F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 5ED4EA0009D9 for ; Tue, 16 Mar 2021 20:17:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615925857; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rAH+Y0PqchePCmc63qPqb547JnFTHPCLfyKXcC3d+MU=; b=HeDd9xfKnrFdmT4aHteJuneiJbxTtXdgQ8gPU5yzNng7xRt2mijSBVSZiFbADH1ztAD8zd Bx43wLKTyklTXGSCFnU989sxtAwzNj6i8cO0Y6qM3lbIh7jVFv4mDmR6eKLyU+hYbkew4M aUlsix2FZlBVznj+DT1PA1PTKbW6SvQ= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-72-rwQFTsyROEi2XPWASLfXQg-1; Tue, 16 Mar 2021 16:17:36 -0400 X-MC-Unique: rwQFTsyROEi2XPWASLfXQg-1 Received: by mail-qk1-f199.google.com with SMTP id h134so27738778qke.1 for ; Tue, 16 Mar 2021 13:17:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rAH+Y0PqchePCmc63qPqb547JnFTHPCLfyKXcC3d+MU=; b=UO7EzjIuNmEecwUt/1vUjml8cg5+7JcX031rgnUJ7q6alfEM2ZhaAkl9C6M4ATnhWt MJviUkNTMOW8Q2RjawG+vGiSwJOrjszBT4nbCXVp7gEpSs3nRRpwLREBXqfwpLOjBWIt kO6hzzR6dKwLkZCoiz7ucXHrqusI/WoLENzeSH6cvS5BGt2uge5UVgu6EAmRnCARDka6 30Xpjh2l7Gar+HpNEnCvZVE6GqP7s9vU5B6OnRp+cBrqb7+zyCxrqOqE3sJ/rssUpv8M 0LXaGS2ap41NLvYOIGL0CMqf9T75XINAVe0SqkpGaqzNOPJ9XIVvOmiL9dySsXt4IjH8 2rPA== X-Gm-Message-State: AOAM533gdEmVLFgpybufOTC+zsNhDVn012EUUSb1wtkD7OUS4CLjXhXM Fokg1y2d18JZx3lXxWsZoi48n+qJ3SdQmu6wynC8uqWRH9EZJ6cO0BdfarQuyfAudgEASR5ie0+ mkXq4uchXqEw= X-Received: by 2002:a05:620a:78b:: with SMTP id 11mr925524qka.0.1615925855703; Tue, 16 Mar 2021 13:17:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxg/+/oLCGxaXXk4ILJXSHUGW/63RO3FZxkH6WXEukwCWHHZ1LfWTUVa14nD3PSw3iQ+bTtRw== X-Received: by 2002:a05:620a:78b:: with SMTP id 11mr925478qka.0.1615925855357; Tue, 16 Mar 2021 13:17:35 -0700 (PDT) Received: from xz-x1 ([142.126.89.138]) by smtp.gmail.com with ESMTPSA id k4sm16119463qke.13.2021.03.16.13.17.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 13:17:34 -0700 (PDT) Date: Tue, 16 Mar 2021 16:17:32 -0400 From: Peter Xu To: Hugh Dickins Cc: Brian Geffon , Andrew Morton , Axel Rasmussen , Lokesh Gidra , Mike Rapoport , "Michael S . Tsirkin" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andy Lutomirski , Vlastimil Babka , Andrea Arcangeli , Sonny Rao , Minchan Kim , "Kirill A . Shutemov" , Dmitry Safonov , Michael Kerrisk , Alejandro Colomar Subject: Re: [PATCH] mm: Allow shmem mappings with MREMAP_DONTUNMAP Message-ID: <20210316201732.GD395976@xz-x1> References: <20210303175235.3308220-1-bgeffon@google.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5ED4EA0009D9 X-Stat-Signature: 1itn7edbbmstdh1qq8sfrc7zixurjkjc Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf23; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615925858-716290 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Mar 13, 2021 at 08:19:38PM -0800, Hugh Dickins wrote: > On Wed, 3 Mar 2021, Brian Geffon wrote: > > > Currently MREMAP_DONTUNMAP only accepts private anonymous mappings. This change > > will widen the support to include shmem mappings. The primary use case > > is to support MREMAP_DONTUNMAP on mappings which may have been created from > > a memfd. > > > > Lokesh Gidra who works on the Android JVM, provided an explanation of how such > > a feature will improve Android JVM garbage collection: > > "Android is developing a new garbage collector (GC), based on userfaultfd. The > > garbage collector will use userfaultfd (uffd) on the java heap during compaction. > > On accessing any uncompacted page, the application threads will find it missing, > > at which point the thread will create the compacted page and then use UFFDIO_COPY > > ioctl to get it mapped and then resume execution. Before starting this compaction, > > in a stop-the-world pause the heap will be mremap(MREMAP_DONTUNMAP) so that the > > java heap is ready to receive UFFD_EVENT_PAGEFAULT events after resuming execution. > > > > To speedup mremap operations, pagetable movement was optimized by moving PUD entries > > instead of PTE entries [1]. It was necessary as mremap of even modest sized memory > > ranges also took several milliseconds, and stopping the application for that long > > isn't acceptable in response-time sensitive cases. With UFFDIO_CONTINUE feature [2], > > it will be even more efficient to implement this GC, particularly the 'non-moveable' > > portions of the heap. It will also help in reducing the need to copy (UFFDIO_COPY) > > the pages. However, for this to work, the java heap has to be on a 'shared' vma. > > Currently MREMAP_DONTUNMAP only supports private anonymous mappings, this patch will > > enable using UFFDIO_CONTINUE for the new userfaultfd-based heap compaction." > > > > [1] https://lore.kernel.org/linux-mm/20201215030730.NC3CU98e4%25akpm@linux-foundation.org/ > > [2] https://lore.kernel.org/linux-mm/20210302000133.272579-1-axelrasmussen@google.com/ > > --- > > mm/mremap.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/mm/mremap.c b/mm/mremap.c > > index ec8f840399ed..6934d199da54 100644 > > --- a/mm/mremap.c > > +++ b/mm/mremap.c > > @@ -653,8 +653,7 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr, > > return ERR_PTR(-EINVAL); > > } > > > > - if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) || > > - vma->vm_flags & VM_SHARED)) > > + if (flags & MREMAP_DONTUNMAP && !(vma_is_anonymous(vma) || vma_is_shmem(vma))) > > return ERR_PTR(-EINVAL); > > > > if (is_vm_hugetlb_page(vma)) > > -- > > Yet something to improve... > > Thanks for extending MREMAP_DONTUNMAP to shmem, but I think this patch > goes in the wrong direction, complicating when it should be generalizing: > the mremap syscall is about rearranging the user's virtual address space, > and is not specific to the underlying anonymous or shmem or file object > (though so far you have only been interested in anonymous, and now shmem). > > A better patch would say: > > - if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) || > - vma->vm_flags & VM_SHARED)) > + if ((flags & MREMAP_DONTUNMAP) && > + (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))) > return ERR_PTR(-EINVAL); > > VM_DONTEXPAND is what has long been used on special mappings, to prevent > surprises from mremap changing the size of the mapping: MREMAP_DONTUNMAP > introduced a different way of expanding the mapping, so VM_DONTEXPAND > still seems a reasonable name (I've thrown in VM_PFNMAP there because > it's in the VM_DONTEXPAND test lower down: for safety I guess, and best > if both behave the same - though one says -EINVAL and the other -EFAULT). > > With that VM_DONTEXPAND check in, Dmitry's commit cd544fd1dc92 > ("mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio") > can still be reverted (as you agreed on 28th December), even though > vma_is_anonymous() will no longer protect it. > > Was there an mremap(2) man page update for MREMAP_DONTUNMAP? > Whether or not there was before, it ought to get one now. I'm curious whether it's okay to expand MREMAP_DONTUNMAP to PFNMAP too.. E.g. vfio maps device MMIO regions with both VM_DONTEXPAND|VM_PFNMAP, to me it makes sense to allow the userspace to get such MMIO region remapped/duplicated somewhere else as long as the size won't change. With the strict check as above we kill all those possibilities. Though in that case we'll still need commits like cd544fd1dc92 to protect any customized ->mremap() when they're not supported. Thanks, -- Peter Xu