Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp246648pxy; Tue, 20 Apr 2021 18:04:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy75ZUGnh3NWKljZoHUnEuTQVuIDKUwOKXdNd7xMPWAGJ82SNvk+mYULdl0kzV4HVW1+FZ0 X-Received: by 2002:a05:6402:27d3:: with SMTP id c19mr36063754ede.129.1618967082360; Tue, 20 Apr 2021 18:04:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618967082; cv=none; d=google.com; s=arc-20160816; b=ajMytM7OuTejFlsZeuo6nPLp5firKSOudfWvX7/JDwBDQ4VScVFmk+EXeyKHJK41+x OiY2rg/6jwUwoWE2wzXbfD6MGYSiiq+us1kWEX9YglUI9cxuuf2yMJYKB26JDr75A160 J7wFK4hGiwkqrYmCyqKkZf6nsW4XjS2FD4qA4+6GRAEx+9hq2pexpWVLFW0BBHu0bUnG +uL+75qRszam4haio+3Wub/tZ6o5HHXnKOfWvlZZyI6ddsQY03nTKl/WtAGIKcYI4YLJ ukgaXpjIMdMqvJdmE9Q1LvmViSDr24oamFui60fVX+EtLZbozeD4/o6dyksJocKZsn0n 8Q7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=L8lGFtSTtYe7QCj8558nLeh4ir6XUy3/NvMAR84JMCU=; b=BxJ2gKnH5LfDzZjmTI/3kGtKUcri3zPbvvtHZ0yfO94HhP1RHGyXOm/mr+Dq42hKps CL36JhakmjLFzb6fFZ/ow+Qy9a8s3xdkxjvafK1kNUYrlQO71laVY3p1NJQoYf0pNHKT aXxVEJX2+PXeOQGtmuRcHALIyut5s4LBo2pMVNSxYDi3PxfjpTlJ7fJZG9RuNmTZt19m EjKT706X8yaI5420rtSEytNZhO/EEfqmiLPS91ZpkgxhnqDiOKJzcU1O+sa8h9TG/IOY Wn11aGSrUiQd+lRwF4sZ7Y+4iwtTR9xQTJpjEJBpZtGIpG1T4mwe7YMBF2i+7glO/8fu K6cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M5crLszD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t23si369697ejj.290.2021.04.20.18.04.16; Tue, 20 Apr 2021 18:04:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M5crLszD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234290AbhDUBCo (ORCPT + 99 others); Tue, 20 Apr 2021 21:02:44 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:33849 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234276AbhDUBCn (ORCPT ); Tue, 20 Apr 2021 21:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618966930; 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=L8lGFtSTtYe7QCj8558nLeh4ir6XUy3/NvMAR84JMCU=; b=M5crLszDrJrNv/NNQhtUnQrc/VeqekaC7OxoEWmkSEQVKG+r4QyxedNUywQNdb36vv/CJE gwsTHM7o51TvXkOSjcZAgz6kNC5RzQVKneptTPPvMgZGaqCa/tpGs6UKUMnafwn7nndsue 8DKfNF6fsxPLb2LnyK/2WGGsofLYrsA= 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-460-Dn4JP15CPYq0tHO4vC0ViQ-1; Tue, 20 Apr 2021 21:02:09 -0400 X-MC-Unique: Dn4JP15CPYq0tHO4vC0ViQ-1 Received: by mail-qk1-f199.google.com with SMTP id t126-20020a37aa840000b02902e3c5b3abeaso5575603qke.10 for ; Tue, 20 Apr 2021 18:02:09 -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=L8lGFtSTtYe7QCj8558nLeh4ir6XUy3/NvMAR84JMCU=; b=QaY5HNSuX4Ptw4m0VM13t5mKHHvIcM/7VnVbrJhIcbkXeJTatPl5nJXcgzzd69KilS 4tv1USasReNFqJWCcZsl4urbG2Mm5C4E4TRyu7P/p59nTfCUUccMurTFa+OlMUV1XCmR NSuToTwi8qK/Jlq/Eu9SV42YWPlrG7k02TjuFnl4bnEelK+0jZpVcttBhieduzWUqQfR 96v1LydPcvhLvmnbhj8A0pVMkornzZ+AFDphpeJxd84ecEFcjrp5Vmr3ndda4gcesI0s insmUGM8AsHh06NJa4A7ygz/VTDAurRsI4XP79s+YkxO21jDCHOdndfom3sNbmYt6IJB rkKQ== X-Gm-Message-State: AOAM533tmukoMFOMArSV0p4aLowjd/ArassSpBiHNPazONzqUDziBxFa Dlm+eGvkR6JAyDkdH1Jy/4CQuZSFsFEFOyc74OeapOFDW8l1yrWjAirJ+Ky74YPDknVt/WS2Bli GlJ+bTyOyoemUciFlEPaG/3JC X-Received: by 2002:a05:622a:1103:: with SMTP id e3mr20240299qty.346.1618966928470; Tue, 20 Apr 2021 18:02:08 -0700 (PDT) X-Received: by 2002:a05:622a:1103:: with SMTP id e3mr20240260qty.346.1618966928149; Tue, 20 Apr 2021 18:02:08 -0700 (PDT) Received: from xz-x1 (bras-base-toroon474qw-grc-88-174-93-75-154.dsl.bell.ca. [174.93.75.154]) by smtp.gmail.com with ESMTPSA id c14sm457297qtc.5.2021.04.20.18.02.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Apr 2021 18:02:07 -0700 (PDT) Date: Tue, 20 Apr 2021 21:02:05 -0400 From: Peter Xu To: Axel Rasmussen Cc: Alexander Viro , Andrea Arcangeli , Andrew Morton , Hugh Dickins , Jerome Glisse , Joe Perches , Lokesh Gidra , Mike Kravetz , Mike Rapoport , Shaohua Li , Shuah Khan , Stephen Rothwell , Wang Qing , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, Brian Geffon , "Dr . David Alan Gilbert" , Mina Almasry , Oliver Upton Subject: Re: [PATCH v4 09/10] userfaultfd/shmem: modify shmem_mcopy_atomic_pte to use install_pte() Message-ID: <20210421010205.GH4440@xz-x1> References: <20210420220804.486803-1-axelrasmussen@google.com> <20210420220804.486803-10-axelrasmussen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210420220804.486803-10-axelrasmussen@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021 at 03:08:03PM -0700, Axel Rasmussen wrote: > In a previous commit, we added the mcopy_atomic_install_pte() helper. > This helper does the job of setting up PTEs for an existing page, to map > it into a given VMA. It deals with both the anon and shmem cases, as > well as the shared and private cases. > > In other words, shmem_mcopy_atomic_pte() duplicates a case it already > handles. So, expose it, and let shmem_mcopy_atomic_pte() use it > directly, to reduce code duplication. > > This requires that we refactor shmem_mcopy_atomic_pte() a bit: > > Instead of doing accounting (shmem_recalc_inode() et al) part-way > through the PTE setup, do it beforehand. This frees up > mcopy_atomic_install_pte() from having to care about this accounting, > but it does mean we need to clean it up if we get a failure afterwards > (shmem_uncharge()). > > We can *almost* use shmem_charge() to do this, reducing code > duplication. But, it does `inode->i_mapping->nrpages++`, which would > double-count since shmem_add_to_page_cache() also does this. Missing to mention the lru_cache_add() replacement comment as Hugh commented on this? > > Signed-off-by: Axel Rasmussen > --- > include/linux/userfaultfd_k.h | 5 ++++ > mm/shmem.c | 53 ++++++++--------------------------- > mm/userfaultfd.c | 17 ++++------- > 3 files changed, 22 insertions(+), 53 deletions(-) > > diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h > index 794d1538b8ba..39c094cc6641 100644 > --- a/include/linux/userfaultfd_k.h > +++ b/include/linux/userfaultfd_k.h > @@ -53,6 +53,11 @@ enum mcopy_atomic_mode { > MCOPY_ATOMIC_CONTINUE, > }; > > +extern int mcopy_atomic_install_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, > + struct vm_area_struct *dst_vma, > + unsigned long dst_addr, struct page *page, > + bool newly_allocated, bool wp_copy); > + > extern ssize_t mcopy_atomic(struct mm_struct *dst_mm, unsigned long dst_start, > unsigned long src_start, unsigned long len, > bool *mmap_changing, __u64 mode); > diff --git a/mm/shmem.c b/mm/shmem.c > index 30c0bb501dc9..9bfa80fcd414 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -2378,10 +2378,8 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, > struct address_space *mapping = inode->i_mapping; > gfp_t gfp = mapping_gfp_mask(mapping); > pgoff_t pgoff = linear_page_index(dst_vma, dst_addr); > - spinlock_t *ptl; > void *page_kaddr; > struct page *page; > - pte_t _dst_pte, *dst_pte; > int ret; > pgoff_t max_off; > > @@ -2391,8 +2389,10 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, > > if (!*pagep) { > page = shmem_alloc_page(gfp, info, pgoff); > - if (!page) > - goto out_unacct_blocks; > + if (!page) { > + shmem_inode_unacct_blocks(inode, 1); > + goto out; > + } > > if (!zeropage) { /* COPY */ > page_kaddr = kmap_atomic(page); > @@ -2432,59 +2432,28 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, > if (ret) > goto out_release; > > - _dst_pte = mk_pte(page, dst_vma->vm_page_prot); > - if (dst_vma->vm_flags & VM_WRITE) > - _dst_pte = pte_mkwrite(pte_mkdirty(_dst_pte)); > - else { > - /* > - * We don't set the pte dirty if the vma has no > - * VM_WRITE permission, so mark the page dirty or it > - * could be freed from under us. We could do it > - * unconditionally before unlock_page(), but doing it > - * only if VM_WRITE is not set is faster. > - */ > - set_page_dirty(page); > - } > - > - dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl); > - > - ret = -EFAULT; > - max_off = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); > - if (unlikely(pgoff >= max_off)) > - goto out_release_unlock; > - > - ret = -EEXIST; > - if (!pte_none(*dst_pte)) > - goto out_release_unlock; > - > - lru_cache_add(page); > - > spin_lock_irq(&info->lock); > info->alloced++; > inode->i_blocks += BLOCKS_PER_PAGE; > shmem_recalc_inode(inode); > spin_unlock_irq(&info->lock); > > - inc_mm_counter(dst_mm, mm_counter_file(page)); > - page_add_file_rmap(page, false); > - set_pte_at(dst_mm, dst_addr, dst_pte, _dst_pte); > + ret = mcopy_atomic_install_pte(dst_mm, dst_pmd, dst_vma, dst_addr, > + page, true, false); > + if (ret) > + goto out_release_uncharge; > > - /* No need to invalidate - it was non-present before */ > - update_mmu_cache(dst_vma, dst_addr, dst_pte); > - pte_unmap_unlock(dst_pte, ptl); > + SetPageDirty(page); > unlock_page(page); > ret = 0; > out: > return ret; > -out_release_unlock: > - pte_unmap_unlock(dst_pte, ptl); > - ClearPageDirty(page); > +out_release_uncharge: > delete_from_page_cache(page); > + shmem_uncharge(inode, 1); > out_release: > unlock_page(page); > put_page(page); > -out_unacct_blocks: Will all the "goto out_release" miss one call to shmem_inode_unacct_blocks()? > - shmem_inode_unacct_blocks(inode, 1); > goto out; > } > #endif /* CONFIG_USERFAULTFD */ > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > index 51d8c0127161..3a9ddbb2dbbd 100644 > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -51,18 +51,13 @@ struct vm_area_struct *find_dst_vma(struct mm_struct *dst_mm, > /* > * Install PTEs, to map dst_addr (within dst_vma) to page. > * > - * This function handles MCOPY_ATOMIC_CONTINUE (which is always file-backed), > - * whether or not dst_vma is VM_SHARED. It also handles the more general > - * MCOPY_ATOMIC_NORMAL case, when dst_vma is *not* VM_SHARED (it may be file > - * backed, or not). > - * > - * Note that MCOPY_ATOMIC_NORMAL for a VM_SHARED dst_vma is handled by > - * shmem_mcopy_atomic_pte instead. > + * This function handles both MCOPY_ATOMIC_NORMAL and _CONTINUE for both shmem > + * and anon, and for both shared and private VMAs. > */ > -static int mcopy_atomic_install_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, > - struct vm_area_struct *dst_vma, > - unsigned long dst_addr, struct page *page, > - bool newly_allocated, bool wp_copy) > +int mcopy_atomic_install_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, > + struct vm_area_struct *dst_vma, > + unsigned long dst_addr, struct page *page, > + bool newly_allocated, bool wp_copy) > { > int ret; > pte_t _dst_pte, *dst_pte; > -- > 2.31.1.368.gbe11c130af-goog > -- Peter Xu