Message ID | 20230202112915.867409-3-usama.anjum@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp184022wrn; Thu, 2 Feb 2023 03:33:48 -0800 (PST) X-Google-Smtp-Source: AK7set+JHIOQsSLZ6gJALzxCyBQN/xRIMgSshh2jagb1Ka3HzB6PBbZVdwioQQbsZiK9E53UwYAD X-Received: by 2002:a17:902:e801:b0:196:89ba:349 with SMTP id u1-20020a170902e80100b0019689ba0349mr8030404plg.64.1675337628417; Thu, 02 Feb 2023 03:33:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675337628; cv=none; d=google.com; s=arc-20160816; b=QgdfnliqlUnXkMhirGk6azWv3BmMXlx/X6BGl9fhB6dEzdfaQUuo8RM0V4YQcvAGFF rmYjHLcDQOuhRQH1EkDdg3JP87LL1NKv/e1iv6S0PCp73WJmXqXI1aY5zuAFgeuI3A0j Loxr5z8pw4w/vEUbzIb30g3dAB5Jkz1URD93dzZ4/zFNTuhCWWznFQgncNqugY2JpUCO GYkZvGW2g0rJJqKD3Db8A6WktFgJMJGcY2LcL9YQhXq8Im7jTUU5EpSkkzxyqTy6Ayv3 pi+T8sUEZOj6vYaimUtFMznSo7Azh+YIvS7VmleVRgJOF0gQiGScR3bO4VeIRwO4E8RA ZBjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Qm1b/r5EaArMOm2VfEm0gRCqLh5hnCX7Lg7t/WY9ly0=; b=dVmoYmtGaZfbI+jj2v7xv5NPWGufIpkRoJttNVSguuCqoqQvLakHxEaC2hUP7We13b l4KDZQZHgRHUJgrWV9ewEAaoNs4cERbfxLUqeRPJR348ldmmoWRJGMJozk00OnaJs6EB 73YuT7lhE/TkWzhEE8ulsyyQyKdd0zNkSayITwF7CmPgwDbMP9f+yRMt5o1c84foBh/r bbA6/s82hh1cLEGymQ2tYbdrzdrpyFXKXCqT+Plh+U2X9a2Zq5/q/eFW2hNQuD9TQst2 qJFvgF+Zw1y+5RQ2mLPbEfDb5yqXfPcQkqgd/hjg/dKb7O2pPiKFH4EH4fFnjjEwQ7wo R+FA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=ckNO74WB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t22-20020a1709028c9600b00189e2b9e681si20104013plo.450.2023.02.02.03.33.36; Thu, 02 Feb 2023 03:33:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=ckNO74WB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232063AbjBBLax (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Thu, 2 Feb 2023 06:30:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231959AbjBBLai (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Feb 2023 06:30:38 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C60254577; Thu, 2 Feb 2023 03:30:32 -0800 (PST) Received: from localhost.localdomain (unknown [39.45.165.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id 78CF16602EF0; Thu, 2 Feb 2023 11:30:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1675337430; bh=vLKWj5//Zawv0HDUOAPz3B4soyCTnmWzd0wVrOxevEk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ckNO74WBHEGIncMfejSOR510T/8wB9MB00CaiU+blSg51WPIaE4wcPwxMUkwzV4UU WskrW7Z1biJhLEWhZDkS5uw5BMj/OGVnp6R39bOyPfbFmHnJVsjK9xOgn18wE6hSL5 W2yR+C4iW7Rcblo243JSxZXDeJrZ4OwiyFa9fYu5QkaPtkoEcFTsjfiAlDn4GCegZV opgp6A/vMjwx1Mez8Ebxw++3S/20ewAru2kuXyL0Gn1bOy11bvDbB7FuP/ZfRKXmms SR7wT1jyG9A/JueueH/Yy5/cYdnBqSq4kXb2KMIJR7FyF76zuzTKTTE8b5SM38ww0e awUF+YVxh0iRg== From: Muhammad Usama Anjum <usama.anjum@collabora.com> To: Peter Xu <peterx@redhat.com>, David Hildenbrand <david@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, =?utf-8?b?TWljaGHFgiBNaXJvc8WC?= =?utf-8?b?YXc=?= <emmir@google.com>, Andrei Vagin <avagin@gmail.com>, Danylo Mocherniuk <mdanylo@google.com>, Paul Gofman <pgofman@codeweavers.com>, Cyrill Gorcunov <gorcunov@gmail.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Shuah Khan <shuah@kernel.org>, Christian Brauner <brauner@kernel.org>, Yang Shi <shy828301@gmail.com>, Vlastimil Babka <vbabka@suse.cz>, "Liam R . Howlett" <Liam.Howlett@Oracle.com>, Yun Zhou <yun.zhou@windriver.com>, Suren Baghdasaryan <surenb@google.com>, Alex Sierra <alex.sierra@amd.com>, Muhammad Usama Anjum <usama.anjum@collabora.com>, Matthew Wilcox <willy@infradead.org>, Pasha Tatashin <pasha.tatashin@soleen.com>, Mike Rapoport <rppt@kernel.org>, Nadav Amit <namit@vmware.com>, Axel Rasmussen <axelrasmussen@google.com>, "Gustavo A . R . Silva" <gustavoars@kernel.org>, Dan Williams <dan.j.williams@intel.com>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Greg KH <gregkh@linuxfoundation.org>, kernel@collabora.com Subject: [PATCH v10 2/6] userfaultfd: update documentation to describe UFFD_FEATURE_WP_ASYNC Date: Thu, 2 Feb 2023 16:29:11 +0500 Message-Id: <20230202112915.867409-3-usama.anjum@collabora.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230202112915.867409-1-usama.anjum@collabora.com> References: <20230202112915.867409-1-usama.anjum@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756718828925715181?= X-GMAIL-MSGID: =?utf-8?q?1756718828925715181?= |
Series |
Implement IOCTL to get and/or the clear info about PTEs
|
|
Commit Message
Muhammad Usama Anjum
Feb. 2, 2023, 11:29 a.m. UTC
Explain the difference created by UFFD_FEATURE_WP_ASYNC to the write
protection (UFFDIO_WRITEPROTECT_MODE_WP) mode.
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
---
Documentation/admin-guide/mm/userfaultfd.rst | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On Thu, Feb 02, 2023 at 04:29:11PM +0500, Muhammad Usama Anjum wrote: > Explain the difference created by UFFD_FEATURE_WP_ASYNC to the write > protection (UFFDIO_WRITEPROTECT_MODE_WP) mode. > > Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> > --- > Documentation/admin-guide/mm/userfaultfd.rst | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst > index 83f31919ebb3..4747e7bd5b26 100644 > --- a/Documentation/admin-guide/mm/userfaultfd.rst > +++ b/Documentation/admin-guide/mm/userfaultfd.rst > @@ -221,6 +221,13 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter > you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was > used. > > +If ``UFFD_FEATURE_WP_ASYNC`` is set while calling ``UFFDIO_API`` ioctl, the > +behaviour of ``UFFDIO_WRITEPROTECT_MODE_WP`` changes such that faults for UFFDIO_WRITEPROTECT_MODE_WP is only a flag in UFFDIO_WRITEPROTECT, while it's forbidden only when not specified. > +anon and shmem are resolved automatically by the kernel instead of sending > +the message to the userfaultfd. The hugetlb isn't supported. The ``pagemap`` > +file can be read to find which pages have ``PM_UFFD_WP`` flag set which > +means they are write-protected. Here's my version. Please feel free to do modifications on top. If the userfaultfd context (that has ``UFFDIO_REGISTER_MODE_WP`` registered against) has ``UFFD_FEATURE_WP_ASYNC`` feature enabled, it will work in async write protection mode. It can be seen as a more accurate version of soft-dirty tracking, meanwhile the results will not be easily affected by other operations like vma merging. Comparing to the generic mode, the async mode will not generate any userfaultfd message when the protected memory range is written. Instead, the kernel will automatically resolve the page fault immediately by dropping the uffd-wp bit in the pgtables. The user app can collect the "written/dirty" status by looking up the uffd-wp bit for the pages being interested in /proc/pagemap. The page will be under track of uffd-wp async mode until the page is explicitly write-protected by ``UFFDIO_WRITEPROTECT`` ioctl with the mode flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault that was tracked by async mode userfaultfd-wp is invalid. Currently ``UFFD_FEATURE_WP_ASYNC`` only support anonymous and shmem. Hugetlb is not yet supported.
On 2/9/23 2:31 AM, Peter Xu wrote: > On Thu, Feb 02, 2023 at 04:29:11PM +0500, Muhammad Usama Anjum wrote: >> Explain the difference created by UFFD_FEATURE_WP_ASYNC to the write >> protection (UFFDIO_WRITEPROTECT_MODE_WP) mode. >> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> >> --- >> Documentation/admin-guide/mm/userfaultfd.rst | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst >> index 83f31919ebb3..4747e7bd5b26 100644 >> --- a/Documentation/admin-guide/mm/userfaultfd.rst >> +++ b/Documentation/admin-guide/mm/userfaultfd.rst >> @@ -221,6 +221,13 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter >> you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was >> used. >> >> +If ``UFFD_FEATURE_WP_ASYNC`` is set while calling ``UFFDIO_API`` ioctl, the >> +behaviour of ``UFFDIO_WRITEPROTECT_MODE_WP`` changes such that faults for > > UFFDIO_WRITEPROTECT_MODE_WP is only a flag in UFFDIO_WRITEPROTECT, while > it's forbidden only when not specified. > >> +anon and shmem are resolved automatically by the kernel instead of sending >> +the message to the userfaultfd. The hugetlb isn't supported. The ``pagemap`` >> +file can be read to find which pages have ``PM_UFFD_WP`` flag set which >> +means they are write-protected. > > Here's my version. Please feel free to do modifications on top. > > If the userfaultfd context (that has ``UFFDIO_REGISTER_MODE_WP`` > registered against) has ``UFFD_FEATURE_WP_ASYNC`` feature enabled, it > will work in async write protection mode. It can be seen as a more > accurate version of soft-dirty tracking, meanwhile the results will not > be easily affected by other operations like vma merging. > > Comparing to the generic mode, the async mode will not generate any > userfaultfd message when the protected memory range is written. Instead, > the kernel will automatically resolve the page fault immediately by > dropping the uffd-wp bit in the pgtables. The user app can collect the > "written/dirty" status by looking up the uffd-wp bit for the pages being > interested in /proc/pagemap. > > The page will be under track of uffd-wp async mode until the page is > explicitly write-protected by ``UFFDIO_WRITEPROTECT`` ioctl with the mode > flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault > that was tracked by async mode userfaultfd-wp is invalid. > > Currently ``UFFD_FEATURE_WP_ASYNC`` only support anonymous and shmem. > Hugetlb is not yet supported. > It'll get replaced the documentation. I'll add a suggested by tag as well. Thanks.
diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 83f31919ebb3..4747e7bd5b26 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -221,6 +221,13 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was used. +If ``UFFD_FEATURE_WP_ASYNC`` is set while calling ``UFFDIO_API`` ioctl, the +behaviour of ``UFFDIO_WRITEPROTECT_MODE_WP`` changes such that faults for +anon and shmem are resolved automatically by the kernel instead of sending +the message to the userfaultfd. The hugetlb isn't supported. The ``pagemap`` +file can be read to find which pages have ``PM_UFFD_WP`` flag set which +means they are write-protected. + QEMU/KVM ========