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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5C85C4345F for ; Wed, 24 Apr 2024 08:07:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B8D66B024C; Wed, 24 Apr 2024 04:07:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 06A5D6B024D; Wed, 24 Apr 2024 04:07:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E99F46B024E; Wed, 24 Apr 2024 04:07:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CDFB56B024C for ; Wed, 24 Apr 2024 04:07:09 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 76A44A09C5 for ; Wed, 24 Apr 2024 08:07:09 +0000 (UTC) X-FDA: 82043694978.25.B5B836E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf25.hostedemail.com (Postfix) with ESMTP id B92AAA0006 for ; Wed, 24 Apr 2024 08:07:06 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713946027; a=rsa-sha256; cv=none; b=gVd2XCqKAQ6LUUp6ay7r1WHe/X9pZIZz7wxzhnCvn7TyDlZmT0hK1FYKiJWXWSKNQEsAgH 03VndBSBoX+xREqbRri7q6F85NDRY5Pb1DSCOiQZK5daqBCVztdzS2hHAm+UEtCEp4+WQO L1hwccqLJH2T6r2dEVvWoFKVJTcjQXI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713946027; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s/3YnpdFiX/zx5gDQOIdhB9bgH7ucWB4mTTGOG87YnA=; b=XJMzO681k+SKiLdh9QZDApd+ydygJkHhN32iCZAN2etemOOCHPyKkALRye9sHAg1rOUsGs 3IT0VD3HBVJxYUc6y3b7z87bLvtxH58vHZIfQtgbRgQq7gIYCve40SsCIAaXPqDJ64MXuv O+LRjGCVEkd8IYXxFp1GOb5H3rce97Y= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 57379339; Wed, 24 Apr 2024 01:07:33 -0700 (PDT) Received: from [10.57.74.127] (unknown [10.57.74.127]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23DBD3F64C; Wed, 24 Apr 2024 01:07:04 -0700 (PDT) Message-ID: <6c418d70-a75d-4019-a0f5-56a61002d37a@arm.com> Date: Wed, 24 Apr 2024 09:07:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/5] mm: memory: extend finish_fault() to support large folio Content-Language: en-GB To: Baolin Wang , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ying.huang@intel.com, shy828301@gmail.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <358aefb1858b63164894d7d8504f3dae0b495366.1713755580.git.baolin.wang@linux.alibaba.com> <6aa25e2a-a6b6-4ab7-8300-053ca3c0d748@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B92AAA0006 X-Stat-Signature: 8zbf8z4of8ap886ext5eesyi97z3q9r9 X-Rspam-User: X-HE-Tag: 1713946026-394925 X-HE-Meta: U2FsdGVkX198egvapuSfv/qvDhuKPtgaWOIRpwaS2oWj4oxvrX42lGYQHjXQRlzn0nzwrVtKq39zBHCQ+U15ydTGsrhX9Jet5XfvNx0syvQA2C4920z7VaUf5Pn+MzCKS7HSVKuPTZVuqUWgDzBbthg/MWh2Kc4a3Fg6C6Q9Lu56bqDFjKyNqcXxtceMmo1eeFwC2g+J0O8cbcAoOqUXSfEB+GJ+vuqtAVJXR1iq3KWimXvkAnVisjDKRBwE6Ru7hXNAbnRmP5Lra+gc6ijjVk2MZyiFL90beG9RwqJLN26GmyYI56PyfIl1JaUXr1mBYRGt6bzdQuXl4A2owV8qAb5qHhKUn8xaQRfJLs8tncqxjEj+2HAHZxiiJLXwiKVliRuk7ftIKEMWa2pudVQ9E0DThMEJ/Ef5fne3RqpV3V/YVBGonTFCcNri34RVzMGmNvrxFVmh7ti29D+kzZqQY+h1UmV6Omm1wQEnkQMzNAnZi8KOhq91zEeenowI8dxp05L8pxdpRgLyYfoPW6nIJ8GybL06BuVfw22hwr5KzL0IjNNjAVDG6nfy/K/XNm5MHLEEOKv8lBoPoZHsULOKE4MTkGVAxRl+GKdt3/FLUk28TWDXFoAjzwd1xdP79B2Amd8+/FtLH+bjIfwnjr8HiY8Zkk/BtMzSNgNW4+6TyRKzqkWD9KaAJ15foqgcbB3yrnmkk8RKj3vTIEe+gENKPltvxHUS+uZh2H95vJr3KXWTnkxvS4LrHLA7txJf0WTdI92+aCrp+wUQkoeE2+mkenwrBShqGvRB1JWhcWz1puBKUS9yZQcJNAc2xKtPWFVM/aauPDpVVj/cow7YVFtmiVkQCxs/JJZpuIqGEqNF9sHEUHFHXqUOYHuSuwf35Kz7QYxqLKBUoHUj1Eqhk+qHlNou0kRlFajwH1+uftupuDUNYnvrKnojptfynUjuJz4WoHuWbFfcNP/VPZuj1Uo tQbbB7yN iTlBTrKPHhoKNzKgsVUs7T8R2hKnn+lEmnudg/9lVsJIrWNjEkJgD1Cynrg9dZgZt4ttg/SiVgaV/gjfAEu/8tmTMomY0m6rfBiBwc1EW0q2D5+ahsyf45c/HaZwBQHE/WlV7mSLdFyzAXNb1IEzH+1ehSnAOk7r79dCL53YF6VBYxQRc7vY8Pj+hogAlGFVydWitbaU/JMOZfhFbm9HPXngXec/luiNSnOJmH2WpSc23SlBs+dNEjmDlEg== 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: List-Subscribe: List-Unsubscribe: On 24/04/2024 04:23, Baolin Wang wrote: > > > On 2024/4/23 19:03, Ryan Roberts wrote: >> On 22/04/2024 08:02, Baolin Wang wrote: >>> Add large folio mapping establishment support for finish_fault() as a >>> preparation, >>> to support multi-size THP allocation of anonymous shared pages in the following >>> patches. >>> >>> Signed-off-by: Baolin Wang >>> --- >>>   mm/memory.c | 25 ++++++++++++++++++------- >>>   1 file changed, 18 insertions(+), 7 deletions(-) >>> >>> diff --git a/mm/memory.c b/mm/memory.c >>> index b6fa5146b260..094a76730776 100644 >>> --- a/mm/memory.c >>> +++ b/mm/memory.c >>> @@ -4766,7 +4766,10 @@ vm_fault_t finish_fault(struct vm_fault *vmf) >>>   { >>>       struct vm_area_struct *vma = vmf->vma; >>>       struct page *page; >>> +    struct folio *folio; >>>       vm_fault_t ret; >>> +    int nr_pages, i; >>> +    unsigned long addr; >>>         /* Did we COW the page? */ >>>       if ((vmf->flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) >>> @@ -4797,22 +4800,30 @@ vm_fault_t finish_fault(struct vm_fault *vmf) >>>               return VM_FAULT_OOM; >>>       } >>>   +    folio = page_folio(page); >>> +    nr_pages = folio_nr_pages(folio); >>> +    addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE); >> >> I'm not sure this is safe. IIUC, finish_fault() is called for any file-backed >> mapping. So you could have a situation where part of a (regular) file is mapped >> in the process, faults and hits in the pagecache. But the folio returned by the >> pagecache is bigger than the portion that the process has mapped. So you now end >> up mapping beyond the VMA limits? In the pagecache case, you also can't assume >> that the folio is naturally aligned in virtual address space. > > Good point. Yes, I think you are right, I need consider the VMA limits, and I > should refer to the calculations of the start pte and end pte in do_fault_around(). You might also need to be careful not to increase reported RSS. I have a vague recollection that David once mentioned a problem with fault-around because it causes the reported RSS to increase for the process and this could lead to different decisions in other places. IIRC Redhat had an advisory somewhere with suggested workaround being to disable fault-around. For the anon-shared memory case, it shouldn't be a problem because the user has opted into allocating bigger blocks, but there may be a need to ensure we don't also start eagerly mapping regular files beyond what fault-around is configured for. > >>>       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, >>> -                      vmf->address, &vmf->ptl); >>> +                       addr, &vmf->ptl); >>>       if (!vmf->pte) >>>           return VM_FAULT_NOPAGE; >>>         /* Re-check under ptl */ >>> -    if (likely(!vmf_pte_changed(vmf))) { >>> -        struct folio *folio = page_folio(page); >>> - >>> -        set_pte_range(vmf, folio, page, 1, vmf->address); >>> -        ret = 0; >>> -    } else { >>> +    if (nr_pages == 1 && vmf_pte_changed(vmf)) { >>>           update_mmu_tlb(vma, vmf->address, vmf->pte); >>>           ret = VM_FAULT_NOPAGE; >>> +        goto unlock; >>> +    } else if (nr_pages > 1 && !pte_range_none(vmf->pte, nr_pages)) { >> >> I think you have grabbed this from do_anonymous_page()? But I'm not sure it >> works in the same way here as it does there. For the anon case, if userfaultfd >> is armed, alloc_anon_folio() will only ever allocate order-0. So we end up in > > IMO, the userfaultfd validation should do in the vma->vm_ops->fault() callback, > to make sure the nr_pages is always 1 if userfaultfd is armed. OK. Are you saying there is already logic to do that today? Great! > >> the vmf_pte_changed() path, which will allow overwriting a uffd entry. But here, >> there is nothing stopping nr_pages being greater than 1 when there could be a >> uffd entry present, and you will fail due to the pte_range_none() check. (see >> pte_marker_handle_uffd_wp()). > > So if we do the userfaultfd validation in ->fault() callback, then here we can > use the same logic as with anonymous case.