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 DEFCDE732E6 for ; Thu, 28 Sep 2023 15:30:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52B2F8D00B7; Thu, 28 Sep 2023 11:30:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B4408D0023; Thu, 28 Sep 2023 11:30:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 354B18D00B7; Thu, 28 Sep 2023 11:30:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1FD328D0023 for ; Thu, 28 Sep 2023 11:30:23 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D9654160F49 for ; Thu, 28 Sep 2023 15:30:22 +0000 (UTC) X-FDA: 81286392684.18.877BCA5 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf19.hostedemail.com (Postfix) with ESMTP id E561D1A0031 for ; Thu, 28 Sep 2023 15:30:20 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SRutN16Z; spf=pass (imf19.hostedemail.com: domain of jannh@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695915021; 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:dkim-signature; bh=gW3bQkxv5ZlVvPDaRZ7GOUnQxOQtKH5unki4YKmOzgQ=; b=7rAAb7GEjI0W7hXlMmky7mZVZU5P6Pl226Kwm14nHYORekMzvzrjtxvHHI7/jaJsskDKgd hfPPC8QjBM2Mmz2ebPBQVdIFh7Se/U5NdE94CIKihYnCERSr66b3GeCP9HlI6C0NVjic4d +HXGnlsJxwGPhIRIalu8l7tntz+OW8w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695915021; a=rsa-sha256; cv=none; b=OwRrJXl2P6X5bVS6GV/duzfAxtPk8zQUpdHk1DBDnO3Vu46RLxQJTu35BjRJPBfg816DcU iB3zhzILqs7ATTa05t0rzDOMr1I3Vxxo89rItcb0AEHsj2XTYt8aphhNzhNht3NwX11HoJ YfBSs3dOpgSSX3FrO5QdiLM+vWxGME8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SRutN16Z; spf=pass (imf19.hostedemail.com: domain of jannh@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1c6193d6bb4so206105ad.0 for ; Thu, 28 Sep 2023 08:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695915019; x=1696519819; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gW3bQkxv5ZlVvPDaRZ7GOUnQxOQtKH5unki4YKmOzgQ=; b=SRutN16Z2Z1WUM88a4/PDjvz1c9sqIV4yE4ffzz2EWzMWT2k2KVVzVA57zrK6gD10i mPili8zJXZ60trH8LbxDDbFHKT1zTTvu4CCe2nO7VdmGZztVInXNuyp7T8PhWJAr93kV 8Sbc3U09h7zsnAQ3n28UKf2vxRoiWXGnbTY8L9Vsp+QNFwcpz0dQmWiufSleOABaGsDZ wUdiTHjR77n1fc0S+ndNOrzhiqDUciGkNrGBfgF87HVgyYbvwR2SMH007DcJxTS0m/Uz vq4em1C+8Rb9f5ephN2bM2+ACRZlmXY6u/F6p4viuEi/3uC+NkY8B+Yl/g9ybJUTQ90D A96Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695915019; x=1696519819; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gW3bQkxv5ZlVvPDaRZ7GOUnQxOQtKH5unki4YKmOzgQ=; b=piezfsyvZKLFubkAujFsC5mf15dZoZ978gULRDIJhiBei2AVIifaR+wMQD+w0afwOF XhHwOFSHb611YZbnBoD0Kb0ARBehX6yRSyVumgCCW0Wj/+Uymvh46l02wAvqD05ZYfNf U6oCmSQPuw7ROELXMkikgziLPxDSYo2mspisVeFcPafqz874vZ8tB5nhcR9ngV1z9VEw wRNIxEulRHs/9LMheiuavCzDS+anbd4k6lk/ETKEObVAOmx0eUQpD0ZPUlrn3zFxLVGf 744uTs1aZj6HRLfIw7T3xgqtAQpnGty/4LHjp6jynP9YkQ/cNHksv/EiJvV4BFkx3BW5 sS1A== X-Gm-Message-State: AOJu0YyWXGaYVXcchYgAEaNUNzDfEKZsZzE+ZGamZSE0IcRu+lvqPTIr mcDbm9tYfjY/t8MZ82J/vcjVYqFuPAnQ9RPYlcb0LA== X-Google-Smtp-Source: AGHT+IHHyfIM/7h2yPICm3uZHEnv53ZDC4+2b2+nBKsf/B6JPSxSiNPVillmryDthljWo4bey1UqJpEOBpTCWBBBy5E= X-Received: by 2002:a17:902:9a85:b0:1c4:1392:e4b5 with SMTP id w5-20020a1709029a8500b001c41392e4b5mr686821plp.21.1695915019275; Thu, 28 Sep 2023 08:30:19 -0700 (PDT) MIME-Version: 1.0 References: <20230923013148.1390521-1-surenb@google.com> <20230923013148.1390521-3-surenb@google.com> In-Reply-To: From: Jann Horn Date: Thu, 28 Sep 2023 17:29:43 +0200 Message-ID: Subject: Re: potential new userfaultfd vs khugepaged conflict [was: Re: [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI] To: Suren Baghdasaryan Cc: Hugh Dickins , Andrew Morton , Al Viro , brauner@kernel.org, Shuah Khan , Andrea Arcangeli , Lokesh Gidra , Peter Xu , David Hildenbrand , Michal Hocko , Axel Rasmussen , Mike Rapoport , willy@infradead.org, Liam.Howlett@oracle.com, zhangpeng362@huawei.com, Brian Geffon , Kalesh Singh , Nicolas Geoffray , Jared Duke , Linux-MM , linux-fsdevel , kernel list , "open list:KERNEL SELFTEST FRAMEWORK" , kernel-team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: pmekhz6xz5iwxdtsttuk691m1j91bstw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E561D1A0031 X-Rspam-User: X-HE-Tag: 1695915020-360834 X-HE-Meta: U2FsdGVkX193se2sZ3GH11PH/qXcjzaE/Pfu28ceVrl7DpH/asT5Ywm0Ag96lvwaRXZUAaK9nnL5nIIVTUxNfHpuZEb0aXQ/li0Lj8Jrcn2FP799ebopfSMl9GhdOPXphbRvIB/YNe9i8eLFx2ABUe5zihyYjfujsf8Dr1JNtPIcenN3IGJj6Ehz2ZxyBss5zlqiJk+Q0wEz0yIFnyKJabeeS43of9dc625LvobsjHy4ZxAoqNhsx2mdrSzmYkBbLWF+BVumHmmxyT7JfJjlibkcleEDPdHqXg471VDoRwtJv0f3ihf8zDRFkA4Jt7/BJIa33DnFveIhpqW7j5819c2Pkxqgm8gxuUCWH/UJ+R2AWxx71xtSIiXRpTgPRdyBU9u6OsTZ1/Lisz/9RocmwELto2Ou4tuSTBU+cxFUXwCggo5+miXXOywW8dyDrx/wWRU4CwV2p+fdKnw7YUc/VAl03LnvSGXbhUXSAHT4e68CSmTO7SYkSAVq8sl95dt5XI9ZA3dSZofLuwWpyc3Ud5iJXt4LwqsI4e+LSQxGTy9i/zlRvL9kyiwJpIVUsuqB+Y0xpIE61v7VnTtyNOjGXXYNdxIMdxtSBNAPQS0GRQcCAs3IztXH2O0PnZkSwWbvjP5GmZCK2G5MseiWOS+F+FDND9cVNFDfi9iHeXfltwFUjsZhvqblGegoW/z4b2rZUdV3URpKmLB37u+CPCsvv5Mx6mcPOzfpRQCAaqCviRZ3+8chVZT8yrCbk2N2nNzjJve/skozU61wJ0gHwzuOv0Din1+KhpTkBcRjeFPzLmrO7slnViRHnGkYa7tOImtYvKskomMyg3t/RLVDDZEszxUsTUXoQqz9ulSJBRHDwLf/QaRmk12x7kylitp7cj+C2MibNJXKBxnHJArH4/gyMRvd04wDxRmiHNASNo7XIbg4PdTUBcymE3PRdnIn5csh5F5iJskLJBgiXCASsKY 8/vAIbG5 vunrVHCSJJhHgGPzOvIkTxrIzmHomV2lN+mVKEbquAB4PuqBgr/JYJq0J+XlOG09t+y3KH0OIrNaP+SnXhfAeGSpdMiS1JExf3Xn6BukcaaSAmo9VtQUczqnvg1JaXyImNi/XjgioVpFE4G/yrg3Nl2Y5AiUI2k0CKl6HlF8Spi+4vKy7IQMRMe/e1IWAxxgxYRZxGdWTaz7SLCDgf2mvzl2qB/5FzJqRMBeDc2ahjapfOO8a3kA0U5KVXuK8rpjqQsNX18IVwLcgFCZk0KWAR4ARMVoM3avsHYI4547O9kwVi/x1e8tCrpEyRTxTSl1OZQJBJKqrYj9dsMo= 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 Wed, Sep 27, 2023 at 7:12=E2=80=AFPM Suren Baghdasaryan wrote: > > On Wed, Sep 27, 2023 at 3:07=E2=80=AFAM Jann Horn wrot= e: > > > > [moving Hugh into "To:" recipients as FYI for khugepaged interaction] > > > > On Sat, Sep 23, 2023 at 3:31=E2=80=AFAM Suren Baghdasaryan wrote: > > > From: Andrea Arcangeli > > > > > > This implements the uABI of UFFDIO_REMAP. > > > > > > Notably one mode bitflag is also forwarded (and in turn known) by the > > > lowlevel remap_pages method. > > > > > > Signed-off-by: Andrea Arcangeli > > > Signed-off-by: Suren Baghdasaryan > > [...] > > > +/* > > > + * The mmap_lock for reading is held by the caller. Just move the pa= ge > > > + * from src_pmd to dst_pmd if possible, and return true if succeeded > > > + * in moving the page. > > > + */ > > > +static int remap_pages_pte(struct mm_struct *dst_mm, > > > + struct mm_struct *src_mm, > > > + pmd_t *dst_pmd, > > > + pmd_t *src_pmd, > > > + struct vm_area_struct *dst_vma, > > > + struct vm_area_struct *src_vma, > > > + unsigned long dst_addr, > > > + unsigned long src_addr, > > > + __u64 mode) > > > +{ > > > + swp_entry_t entry; > > > + pte_t orig_src_pte, orig_dst_pte; > > > + spinlock_t *src_ptl, *dst_ptl; > > > + pte_t *src_pte =3D NULL; > > > + pte_t *dst_pte =3D NULL; > > > + > > > + struct folio *src_folio =3D NULL; > > > + struct anon_vma *src_anon_vma =3D NULL; > > > + struct mmu_notifier_range range; > > > + int err =3D 0; > > > + > > > + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, src_mm, > > > + src_addr, src_addr + PAGE_SIZE); > > > + mmu_notifier_invalidate_range_start(&range); > > > +retry: > > > + dst_pte =3D pte_offset_map_nolock(dst_mm, dst_pmd, dst_addr, = &dst_ptl); > > > + > > > + /* If an huge pmd materialized from under us fail */ > > > + if (unlikely(!dst_pte)) { > > > + err =3D -EFAULT; > > > + goto out; > > > + } > > > + > > > + src_pte =3D pte_offset_map_nolock(src_mm, src_pmd, src_addr, = &src_ptl); > > > + > > > + /* > > > + * We held the mmap_lock for reading so MADV_DONTNEED > > > + * can zap transparent huge pages under us, or the > > > + * transparent huge page fault can establish new > > > + * transparent huge pages under us. > > > + */ > > > + if (unlikely(!src_pte)) { > > > + err =3D -EFAULT; > > > + goto out; > > > + } > > > + > > > + BUG_ON(pmd_none(*dst_pmd)); > > > + BUG_ON(pmd_none(*src_pmd)); > > > + BUG_ON(pmd_trans_huge(*dst_pmd)); > > > + BUG_ON(pmd_trans_huge(*src_pmd)); > > > > This works for now, but note that Hugh Dickins has recently been > > reworking khugepaged such that PTE-based mappings can be collapsed > > into transhuge mappings under the mmap lock held in *read mode*; > > holders of the mmap lock in read mode can only synchronize against > > this by taking the right page table spinlock and rechecking the pmd > > value. This is only the case for file-based mappings so far, not for > > anonymous private VMAs; and this code only operates on anonymous > > private VMAs so far, so it works out. > > > > But if either Hugh further reworks khugepaged such that anonymous VMAs > > can be collapsed under the mmap lock in read mode, or you expand this > > code to work on file-backed VMAs, then it will become possible to hit > > these BUG_ON() calls. I'm not sure what the plans for khugepaged going > > forward are, but the number of edgecases everyone has to keep in mind > > would go down if you changed this function to deal gracefully with > > page tables disappearing under you. > > > > In the newest version of mm/pgtable-generic.c, above > > __pte_offset_map_lock(), there is a big comment block explaining the > > current rules for page table access; in particular, regarding the > > helper pte_offset_map_nolock() that you're using: > > > > * pte_offset_map_nolock(mm, pmd, addr, ptlp), above, is like pte_offse= t_map(); > > * but when successful, it also outputs a pointer to the spinlock in pt= lp - as > > * pte_offset_map_lock() does, but in this case without locking it. Th= is helps > > * the caller to avoid a later pte_lockptr(mm, *pmd), which might by th= at time > > * act on a changed *pmd: pte_offset_map_nolock() provides the correct = spinlock > > * pointer for the page table that it returns. In principle, the calle= r should > > * recheck *pmd once the lock is taken; in practice, no callsite needs = that - > > * either the mmap_lock for write, or pte_same() check on contents, is = enough. > > > > If this becomes hittable in the future, I think you will need to > > recheck *pmd, at least for dst_pte, to avoid copying PTEs into a > > detached page table. > > Thanks for the warning, Jann. It sounds to me it would be better to > add this pmd check now even though it's not hittable. Does that sound > good to everyone? Sounds good to me.