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 ABF5BC433EF for ; Mon, 6 Jun 2022 22:26:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AF656B0072; Mon, 6 Jun 2022 18:26:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3371F6B0073; Mon, 6 Jun 2022 18:26:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B0E06B0074; Mon, 6 Jun 2022 18:26:53 -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 062926B0072 for ; Mon, 6 Jun 2022 18:26:53 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CFCA73441D for ; Mon, 6 Jun 2022 22:26:52 +0000 (UTC) X-FDA: 79549247064.22.F2CD9E8 Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by imf04.hostedemail.com (Postfix) with ESMTP id F144740041 for ; Mon, 6 Jun 2022 22:26:30 +0000 (UTC) Received: by mail-il1-f178.google.com with SMTP id d6so2149772ilm.4 for ; Mon, 06 Jun 2022 15:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7+m4F9TCs6wwlDfh4xzlLWJ0fsAvrpfSsmLzEzUCyW8=; b=jEf7G6uOpfiU1hbpTHgk3NId4v+ja1qTHA3pAf/MXR83PREEt8rWvFLIQRwA5OtTIZ zS+jXUiY2u8iqWFQ5ps7AUA+Bl6xmoJdUeM0VlFrDgo7gUtDS+Gn5FhBK4saFxCd44CB TGA3erXCt4a9he7FBmfseVnex+OBNfpRd0pj60/QAf4G95xZH3G7lHUFI8ghNbnoMRrf sMe058SFWLkMj5QOhvSfgCgIK66oAbzbOgrq2pGaTFIBZuHbBqEmohlroeJJEjKHasH/ /9O2y1fA/PTP6r4XqmIXYm//OmNtD0RvjmneRFxKCFH68de1zKb6kIL7NKaDjciqHPMg fsCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7+m4F9TCs6wwlDfh4xzlLWJ0fsAvrpfSsmLzEzUCyW8=; b=VQS0mlJaMfRYWAv6DEzYHyByc/ZkrJd/Zpk3XJbaWnZ/kmak+kvN76TuqgEAYlRq+w UFXyqVxgG+qis1Z5WzdVrKxzMaJkbGdwLlllHP3kZUtycO03c9TBy9luq3O93DJTykV5 FSY9b0QuH16TBOsbhLOgzacZcGbqAafDQWL1AWgvQlb8JueeAPGj5V+4nkLj/V2pnIVK ORzqjx1BVpy5pn5wCZLrvHIN96L6D6QptehUlZJY0UDjvabu+3IcjeILAyXLOtuYljeW NQTuxdv2C1NCH9524nFyT+KjagrfZzpFSDEzut44HUH8/7YTCmqfpARAPEP0lky6CpEd AGTw== X-Gm-Message-State: AOAM533lYssNtZ5XzI8oiCOk08YmNA4bSoxUMd+qUkgpkJZyp/EdX/ab 6tW5Z4GsE0YaGDDN6kTb3vdb7KFVZOj7YCIRWd0ccw== X-Google-Smtp-Source: ABdhPJwif0tuHBY2ezEHoAV0rxYUPjDDfNMbghivKRqtgjPmjCFL01jKMjDITTXWLkxOdO+s46uPnG0kQQAd2yN0ZNQ= X-Received: by 2002:a05:6e02:1d8b:b0:2d3:9914:16f with SMTP id h11-20020a056e021d8b00b002d39914016fmr15056338ila.239.1654554411219; Mon, 06 Jun 2022 15:26:51 -0700 (PDT) MIME-Version: 1.0 References: <20220603173736.62581-1-peterx@redhat.com> <7acfdeb8-5dd3-dfe2-5717-b64006281a8f@gmail.com> In-Reply-To: From: Axel Rasmussen Date: Mon, 6 Jun 2022 15:26:15 -0700 Message-ID: Subject: Re: [PATCH v2 0/2] userfaultfd.2: Update to latest To: Peter Xu Cc: Alejandro Colomar , LKML , linux-man@vger.kernel.org, Linux MM , Andrea Arcangeli , Nadav Amit , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: F144740041 X-Stat-Signature: 1pz1dr76s8yipm7weheyow96r1dsfqw6 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jEf7G6uO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=axelrasmussen@google.com X-HE-Tag: 1654554390-319007 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 Mon, Jun 6, 2022 at 12:40 PM Peter Xu wrote: > > On Mon, Jun 06, 2022 at 08:52:25PM +0200, Alejandro Colomar wrote: > > Hi Peter, > > Hi, Alex, > > > > > On 6/3/22 19:37, Peter Xu wrote: > > > v2: > > > - Use semantic newlines always in patch 1 [Alex] > > > - Fix s/.BR/.B/ in patch 2 [Alex] > > > - Rebased to http://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git > > > > > > Add the two missing pieces till latest 5.19-rc1: the UFFD_USER_MODE_ONLY > > > flag, and also the recent wr-protect support on shmem and hugetlbfs. > > > > > > Please review, thanks. > > > > > > Peter Xu (2): > > > userfaultfd.2: Add section for UFFD_USER_MODE_ONLY > > > userfaultfd.2: Update on write-protection support > > > > > > man2/userfaultfd.2 | 23 ++++++++++++++++++----- > > > 1 file changed, 18 insertions(+), 5 deletions(-) > > > > > > > > > I think the patch below would improve a little bit the wording (and > > newlines). I still have a bit of trouble understanding "When a > > kernel-originated fault was triggered on the registered range with this > > userfaultfd". Did you maybe mean "range registered" instead of "registered > > range"? > > Since I'm not a native speaker I don't immediately see the difference > between the two.. What I wanted to express is all the memory ranges that > we registered with UFFDIO_REGISTER ioctl, and further it was trying to > describe what the kernel will do when there're any page faults that were > triggered upon those ranges from a kernel context. > > It's always challenging for me to grasp how you prefer the newlines are > made, but anyway below changes looks good to me. Thanks, I think "range registered" Alejandro suggested is a bit more natural, just because that's the way you'd say it if we were slightly more verbose: "When a kernel-originated fault was triggered on the range [that was previously] registered with this userfaultfd, ..." Of course leaving out "that was previously" is fine, but I think the ordering "range registered" remains more natural. Another alternative I find equally natural which keeps the existing ordering might be something like: "... on the userfaultfd-registered range ..." > > > > > Thanks, > > > > Alex > > > > > > diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 > > index 9b5ec0358..0c0a4f687 100644 > > --- a/man2/userfaultfd.2 > > +++ b/man2/userfaultfd.2 > > @@ -62,11 +62,11 @@ flag in > > .BR open (2). > > .TP > > .B UFFD_USER_MODE_ONLY > > -This is an userfaultfd specific flag that was introduced since Linux 5.11. > > -When set, the userfaultfd object will only be able to handle page faults > > -originated from the userspace on the registered regions. > > -When a kernel originated fault was triggered on the registered range with > > -this userfaultfd, a > > +This is an userfaultfd-specific flag that was introduced in Linux 5.11. > > +When set, the userfaultfd object will only be able to handle > > +page faults originated from the user space on the registered regions. > > +When a kernel-originated fault was triggered > > +on the registered range with this userfaultfd, a > > .B SIGBUS > > signal will be delivered. > > .PP > > @@ -277,8 +277,9 @@ ioctl against the feature bit > > .B UFFD_FEATURE_PAGEFAULT_FLAG_WP > > before using this feature. > > .PP > > -Since Linux 5.19, the write-protection mode was also supported on shmem and > > hugetlbfs > > -memory types. > > +Since Linux 5.19, > > +the write-protection mode was also supported on > > +shmem and hugetlbfs memory types. > > It can be detected with the feature bit > > .BR UFFD_FEATURE_WP_HUGETLBFS_SHMEM . > > .PP > > > > > > -- > > Alejandro Colomar > > > > > > > -- > Peter Xu >