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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,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 8E8AEC4707F for ; Wed, 26 May 2021 00:16:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFDCD613B6 for ; Wed, 26 May 2021 00:16:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFDCD613B6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2800C6B006C; Tue, 25 May 2021 20:16:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 214B06B006E; Tue, 25 May 2021 20:16:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFFC66B0070; Tue, 25 May 2021 20:16:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 7A7AC6B006C for ; Tue, 25 May 2021 20:16:01 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 13E0B98BE for ; Wed, 26 May 2021 00:16:01 +0000 (UTC) X-FDA: 78181464522.20.7906352 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP id 424828019116 for ; Wed, 26 May 2021 00:15:54 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 2E09E61028; Wed, 26 May 2021 00:15:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1621988159; bh=P1mc1cqe6xqa0UqfbAJ+UR2ifYfKaOn6a7141BVg19c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DquXfRw5RI/pndSzZWTrvs3rihvaeTxONkNXRw9LAMhytg64gRDl/IQTuO2BtvViU /goY+9FLD0uPKYUnw0dxb/44e7HGAmFyO+bnIL33ikfX5jDuMJol1PwWzd7uZWfefQ +YfATwrZylk/7IHX0Lny/6s1PFNmFV6YGw1740GI= Date: Tue, 25 May 2021 17:15:58 -0700 From: Andrew Morton To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz , Mike Rapoport , Axel Rasmussen , Andrea Arcangeli , Hugh Dickins , "Kirill A . Shutemov" , Jerome Glisse Subject: Re: [PATCH 2/6] mm/userfaultfd: Fix uffd-wp special cases for fork() Message-Id: <20210525171558.3b223a89c16bdf002f3e83cf@linux-foundation.org> In-Reply-To: <20210428225030.9708-3-peterx@redhat.com> References: <20210428225030.9708-1-peterx@redhat.com> <20210428225030.9708-3-peterx@redhat.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=DquXfRw5; spf=pass (imf08.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 424828019116 X-Stat-Signature: 5d8jacijm6du8knkm8o49cjt8wgjtgnx X-HE-Tag: 1621988154-712644 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, 28 Apr 2021 18:50:26 -0400 Peter Xu wrote: > We tried to do something similar in b569a1760782 ("userfaultfd: wp: drop > _PAGE_UFFD_WP properly when fork") previously, but it's not doing it all > right.. A few fixes around the code path: > > 1. We were referencing VM_UFFD_WP vm_flags on the _old_ vma rather than the > new vma. That's overlooked in b569a1760782, so it won't work as expected. > Thanks to the recent rework on fork code (7a4830c380f3a8b3), we can easily > get the new vma now, so switch the checks to that. > > 2. Dropping the uffd-wp bit in copy_huge_pmd() could be wrong if the huge pmd > is a migration huge pmd. When it happens, instead of using pmd_uffd_wp(), > we should use pmd_swp_uffd_wp(). The fix is simply to handle them separately. > > 3. Forget to carry over uffd-wp bit for a write migration huge pmd entry. > This also happens in copy_huge_pmd(), where we converted a write huge > migration entry into a read one. > > 4. In copy_nonpresent_pte(), drop uffd-wp if necessary for swap ptes. > > 5. In copy_present_page() when COW is enforced when fork(), we also need to > pass over the uffd-wp bit if VM_UFFD_WP is armed on the new vma, and when > the pte to be copied has uffd-wp bit set. > > Remove the comment in copy_present_pte() about this. It won't help a huge lot > to only comment there, but comment everywhere would be an overkill. Let's > assume the commit messages would help. > This run afoul of Alistair's "mm: Device exclusive memory access", https://lkml.kernel.org/r/20210524132725.12697-8-apopple@nvidia.com `vma' is now undeclared. I think this? --- a/mm/memory.c~mm-userfaultfd-fix-uffd-wp-special-cases-for-fork-fix +++ a/mm/memory.c @@ -850,8 +850,8 @@ copy_nonpresent_pte(struct mm_struct *ds * exclusive entries currently only support private writable * (ie. COW) mappings. */ - VM_BUG_ON(!is_cow_mapping(vma->vm_flags)); - if (try_restore_exclusive_pte(src_mm, src_pte, vma, addr)) + VM_BUG_ON(!is_cow_mapping(dst_vma->vm_flags)); + if (try_restore_exclusive_pte(src_mm, src_pte, dst_vma, addr)) return -EBUSY; return -ENOENT; } _