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=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,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 6C72AC433E0 for ; Thu, 4 Mar 2021 16:02:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F293E64E6F for ; Thu, 4 Mar 2021 16:02:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F293E64E6F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F9496B0010; Thu, 4 Mar 2021 11:02:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CD446B0012; Thu, 4 Mar 2021 11:02:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76E846B0022; Thu, 4 Mar 2021 11:02:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 58AD16B0010 for ; Thu, 4 Mar 2021 11:02:32 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 150D5283D for ; Thu, 4 Mar 2021 16:02:32 +0000 (UTC) X-FDA: 77882659344.11.CF88D2D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 1C4712000DAC for ; Thu, 4 Mar 2021 16:02:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614873744; 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=JyhQgjgYAeNA8irgyR25lH7TE7Jy6HFJBHARivwr8OM=; b=Dal3Gz3DptB6AkZq7O3cT6fXQKNH5gt0hWG4RqYuLYQFGh+/sQBBu+eO1TMW3RARFshIy5 TCxv8PxI2q226TFK8teuZeOwmBLI0AI+3iT/KjMrk/jTwwWgdixr6wroXlAyrPE1WBQ27H 7MIE5lcNsky8CMSk1D25CKGTaHvAPP8= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-22-0cdpvXDkPU2XCtyiFS5_4Q-1; Thu, 04 Mar 2021 11:02:20 -0500 X-MC-Unique: 0cdpvXDkPU2XCtyiFS5_4Q-1 Received: by mail-qv1-f69.google.com with SMTP id b15so12744810qvz.15 for ; Thu, 04 Mar 2021 08:02:20 -0800 (PST) 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=JyhQgjgYAeNA8irgyR25lH7TE7Jy6HFJBHARivwr8OM=; b=JTPBo9X/0C02NS3/TdPX5kpPo1FmT+POUGYaxWZGJ9piqnEUtlcjsCvbwxmJkMAYTv F73P9E7/ohMjk9M3cXotWFTNJCflzrMRDM7KIuNx8MDoiopng8KvNLeKP73V68rRfS2K 3ldBOB5dWYtPcbXih6ywB6qxSr+eU4ffrGdaqdpT+HH0E+Ab/ygJehgmRGMi/AxvAXhD nPWQlAR84jSICC4bAk0THVnbbWP9bjhA45DPgtAqIEOxPQHgYATiswAaOmrrZZdIOmma Tgf5kzsQ81iSwXR/ogphByi5Y/fcAFLDSJmABYumVMadqKSxnNBFL5MzzL4IKMhzq7Ot wLEQ== X-Gm-Message-State: AOAM531JaswBNqcV1ReQivVJw0YARlaUzvs2FyNEPr73LbWx8XK8OTzB 4dFYBRiqym8kwTzpLaE6epVInVg4Hze1rNMJnIdbRUR1dyRu4XY9Jz8aSXDx8OfvJBgVRluCJYL Gz4ngPpFoXVQ= X-Received: by 2002:ac8:5bcb:: with SMTP id b11mr4636472qtb.310.1614873740328; Thu, 04 Mar 2021 08:02:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJx5Lyy/zDh1+PpGE8wHcCei1D2bsSt5aapooa52RLuVDDDwjzid/TcvOdpJbcc/4ZwrtzyVzg== X-Received: by 2002:ac8:5bcb:: with SMTP id b11mr4636430qtb.310.1614873740014; Thu, 04 Mar 2021 08:02:20 -0800 (PST) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-25-174-95-95-253.dsl.bell.ca. [174.95.95.253]) by smtp.gmail.com with ESMTPSA id e5sm4763214qtq.1.2021.03.04.08.02.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Mar 2021 08:02:19 -0800 (PST) Date: Thu, 4 Mar 2021 11:02:17 -0500 From: Peter Xu To: Mike Rapoport Cc: linux-man@vger.kernel.org, Mike Rapoport , Nadav Amit , linux-kernel@vger.kernel.org, Linux MM Mailing List , Axel Rasmussen , Alejandro Colomar , Andrea Arcangeli , Andrew Morton , Michael Kerrisk Subject: Re: [PATCH 2/4] userfaultfd.2: Add write-protect mode Message-ID: <20210304160217.GZ397383@xz-x1> References: <20210304015947.517713-1-peterx@redhat.com> <20210304015947.517713-3-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1C4712000DAC X-Stat-Signature: 4djx4wjeum5ha81ibhyrdwei8ih7bpaz Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614873746-654448 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 Thu, Mar 04, 2021 at 08:46:59AM +0200, Mike Rapoport wrote: > On Wed, Mar 03, 2021 at 08:59:45PM -0500, Peter Xu wrote: > > Write-protect mode is supported starting from Linux 5.7. > > > > Signed-off-by: Peter Xu > > --- > > man2/userfaultfd.2 | 88 ++++++++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 86 insertions(+), 2 deletions(-) > > > > diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 > > index 2d14effc6..8e1602d62 100644 > > --- a/man2/userfaultfd.2 > > +++ b/man2/userfaultfd.2 > > @@ -78,6 +78,28 @@ all memory ranges that were registered with the object are unregistered > > and unread events are flushed. > > .\" > > .PP > > +Currently, userfaultfd supports two modes of registration: > > +.TP > > +.BR UFFDIO_REGISTER_MODE_MISSING > > +When registered with > > +.BR UFFDIO_REGISTER_MODE_MISSING > > +mode, the userspace will receive a page fault message when a missing page is > > +accessed. The faulted thread will be stopped from execution until the page > > +fault is resolved from the userspace by either an > > +.BR UFFDIO_COPY > > +or an > > +.BR UFFDIO_ZEROPAGE > > +ioctl. > > +.TP > > +.BR UFFDIO_REGISTER_MODE_WP > > +When registered with > > +.BR UFFDIO_REGISTER_MODE_WP > > +mode, the userspace will receive a page fault message when a write-protected > > +page is written. The faulted thread will be stopped from execution until the > > +userspace un-write-protect the page using an > > +.BR UFFDIO_WRITEPROTECT > > +ioctl. > > +.PP > > I'd add a sentence about combining the modes together. Something like > > "Both modes can be enabled together for the same memory range" I mentioned it below [1]. However I agree it's indeed making more sense to mention it when listing the modes, especially knowing that the 3rd minor mode is coming. I think I'll keep both, assuming a bit more verbose is still acceptable in man pages, but changed to: "Multiple modes can be enabled at the same time for the same memory range." > > > Since Linux 4.14, userfaultfd page fault message can selectively embed fault > > thread ID information into the fault message. One needs to enable this feature > > explicitly using the > > @@ -143,6 +165,16 @@ single threaded non-cooperative userfaultfd manager implementations. > > .\" and limitations remaining in 4.11 > > .\" Maybe it's worth adding a dedicated sub-section... > > .\" > > +.PP > > +Starting from Linux 5.7, userfaultfd is able to do synchronous page dirty > > +tracking using the new write-protection register mode. One should check > > +against the feature bit > > +.B UFFD_FEATURE_PAGEFAULT_FLAG_WP > > +before using this feature. Similar to the original userfaultfd missing mode, > > +the write-protect mode will generate an userfaultfd message when the protected > > +page is written. The user needs to resolve the page fault by unprotecting the > > +faulted page and kick the faulted thread to continue. For more information, > > +please read the "Userfaultfd write-protect mode" section below. > > .SS Userfaultfd operation > > After the userfaultfd object is created with > > .BR userfaultfd (), > > @@ -218,6 +250,54 @@ userfaultfd can be used only with anonymous private memory mappings. > > Since Linux 4.11, > > userfaultfd can be also used with hugetlbfs and shared memory mappings. > > .\" > > +.SS Userfaultfd write-protect mode > > +Since Linux 5.7, userfaultfd started to support write-protect mode. The user > > Maybe s/started to support/supports/ Sure. > > > +needs to first check availability of this feature using > > +.BR UFFDIO_API > > +ioctl against the feature bit > > +.BR UFFD_FEATURE_PAGEFAULT_FLAG_WP . > > +.PP > > +To register with userfaultfd write-protect mode, the user needs to send the > > +.BR UFFDIO_REGISTER > > +ioctl with mode > > +.BR UFFDIO_REGISTER_MODE_WP > > +set. Note that it's legal to monitor the same memory range with multiple > > +modes. For example, the user can do > > +.BR UFFDIO_REGISTER > > +with the mode set to > > +.BR UFFDIO_REGISTER_MODE_MISSING\ |\ UFFDIO_REGISTER_MODE_WP. [1] Thanks, -- Peter Xu