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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 2ACCEC433C1 for ; Mon, 22 Mar 2021 13:27:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A67C16191F for ; Mon, 22 Mar 2021 13:27:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A67C16191F 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 713F36B006E; Mon, 22 Mar 2021 09:08:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EBF26B00BE; Mon, 22 Mar 2021 09:08:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 565366B00BF; Mon, 22 Mar 2021 09:08:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 3792E6B006E for ; Mon, 22 Mar 2021 09:08:45 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 973152C78 for ; Mon, 22 Mar 2021 13:27:35 +0000 (UTC) X-FDA: 77947587270.27.0027443 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf04.hostedemail.com (Postfix) with ESMTP id EC6783C0 for ; Mon, 22 Mar 2021 13:27:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616419654; 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=TbWk1Sl1EYOavMer1olo6Jpzca7vciI8lgyKwGdK0Gs=; b=hn06i9QQWKJFzCfaDwwp3gOf3oT1JAWP9i8ynDBGUdzlMlSwvqRsIrRebOzgLkEkbLlBOi L8SY3Gu1bUA/eX1x8HdsHjwA26BweKuXL7L+dp6Ywt9qZ9ZzG0GjD0F6HD3oQwSOz8xZ16 vkM+iFVGh4/Zqw7t6hJ+ORt9qJ9rlys= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-25-nIrhgXCtNsOBoV3goEZkXQ-1; Mon, 22 Mar 2021 09:27:32 -0400 X-MC-Unique: nIrhgXCtNsOBoV3goEZkXQ-1 Received: by mail-qv1-f72.google.com with SMTP id k92so33556327qva.20 for ; Mon, 22 Mar 2021 06:27:32 -0700 (PDT) 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=TbWk1Sl1EYOavMer1olo6Jpzca7vciI8lgyKwGdK0Gs=; b=Vh+w9jbH2x8iXlWOVyGd7NZ66oNccTc3aU45xyE2hY70/It1JeE6EEkC4TOBJ0oguB T6Z/WD6hdBUXA7PoNzIyjUoQAKiraYIbp5gq5D93UmDjtJEEni4Kcn0QLUfod2gLDk+r Srth1KlpYvhVvkr1emhGRwGymcAm8jOuXrwLfwJpqrsrftn2cmGiNYe0LimSflAMTdl9 CfRnTYuVhGGgX5O9p8671obKF+zI1tvG+HA30n70PQR3cWZVDFEshKcAS2gd5DIlvqPM 9PbzULOQMmV6EFUovLgFy8EHUCgu8ruK5ILGnM76snOIueoPeia0Mygpua8TacGsALYu /XCQ== X-Gm-Message-State: AOAM533u4tkK3atB5EYC6VuoA8W+axjwSc2PgjRxsaJFPuE2gED05I3u vF1irZacosqln3DVqRIZACJ2xMPvd8158/yCLTFEen8gDJzmfci7LXPOGjLpdx498EFytxjvD8H k59mnH1HBvLQ= X-Received: by 2002:a05:6214:80a:: with SMTP id df10mr5457qvb.46.1616419652239; Mon, 22 Mar 2021 06:27:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyC/gQ9X/9EFNMDb1RpfZCxrAAff/wp7MDsEz1JJ8PjeoC0NPY0pqXEBIhZbSMC4EICu8+jgg== X-Received: by 2002:a05:6214:80a:: with SMTP id df10mr5415qvb.46.1616419651779; Mon, 22 Mar 2021 06:27:31 -0700 (PDT) Received: from xz-x1 (bras-base-toroon474qw-grc-82-174-91-135-175.dsl.bell.ca. [174.91.135.175]) by smtp.gmail.com with ESMTPSA id k126sm11026555qkb.4.2021.03.22.06.27.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 06:27:30 -0700 (PDT) Date: Mon, 22 Mar 2021 09:27:30 -0400 From: Peter Xu To: Mike Rapoport Cc: Michal Hocko , Bui Quang Minh , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Axel Rasmussen Subject: Re: [PATCH] userfaultfd: Write protect when virtual memory range has no page table entry Message-ID: <20210322132730.GA16645@xz-x1> References: <20210319152428.52683-1-minhquangbui99@gmail.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: EC6783C0 X-Stat-Signature: d5foxa6aqeia3coe1ieswor4ny64grpu Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616419654-802166 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, Mar 22, 2021 at 03:00:37PM +0200, Mike Rapoport wrote: > On Mon, Mar 22, 2021 at 11:14:37AM +0100, Michal Hocko wrote: > > Le'ts Andrea and Mike > > > > On Fri 19-03-21 22:24:28, Bui Quang Minh wrote: > > > userfaultfd_writeprotect() use change_protection() to clear write bit in > > > page table entries (pte/pmd). So, later write to this virtual address > > > range causes a page fault, which is then handled by userspace program. > > > However, change_protection() has no effect when there is no page table > > > entries associated with that virtual memory range (a newly mapped memory > > > range). As a result, later access to that memory range causes allocating a > > > page table entry with write bit still set (due to VM_WRITE flag in > > > vma->vm_flags). > > > > > > Add checks for VM_UFFD_WP in vma->vm_flags when allocating new page table > > > entry in missing page table entry page fault path. > > > > From the above it is not really clear whether this is a usability > > problem or a bug of the interface. > > I'd say it's usability/documentation clarity issue. > Userspace can register an area with > > UFFDIO_REGISTER_MODE_MISSING | UFFDIO_REGISTER_MODE_WP > > and then it will be notified either when page table has no entry for a > virtual address or when there is a write to a write protected address. Right, it's debatable to make it a default behavior since there can be some application that does not care about zero pages - since currently userfaultfd wr-protect only works for anonymous page, so any missing entry means a zero page to be allocated. Currently if we want to wr-protect all pages including zero pages, we can either do as what Mike suggested, or one can pre-read the range to fault in the pages. The double-mode solution should be even better, since then the user app would have a chance to know it's zero page without even scanning it. It'll be a new story for page-cache backed memory regions, and that's indeed the major work contained in the upcoming shmem+hugetlbfs uffd-wp support series [1] to allow persisting uffd-wp/write bit even without page table entries, because then the entry can be null even when there's page cache (so it'll bypass uffdio missing messages too). If this behavior is very desired, how about define a new feature bit, say UFFD_FEATURE_WP_UNALLOCATED? This could be more efficient than registering with two modes, since we can do the later UFFDIO_COPY along with the MISSING page fault as in this patch, meanwhile that'll also contain the same semantic as UFFDIO_ZEROCOPY so less data copy too (UFFDIO_ZEROCOPY does not support UFFDIO_COPY_MODE_WP so far). However we need to be careful on mixture use of these, e.g., I think UFFD_FEATURE_WP_UNALLOCATED at least shouldn't be allowed with UFFDIO_REGISTER_MODE_MISSING, otherwise the behavior of missing fault on uffd-wp area will be undefined. Thoughts? [1] https://lore.kernel.org/lkml/20210115170907.24498-1-peterx@redhat.com/ Thanks, -- Peter Xu