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 DE329C433C1 for ; Tue, 23 Mar 2021 15:12:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 85CB2619C8 for ; Tue, 23 Mar 2021 15:12:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85CB2619C8 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 DE7F76B020C; Tue, 23 Mar 2021 11:12:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBE336B020E; Tue, 23 Mar 2021 11:12:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C37756B020F; Tue, 23 Mar 2021 11:12:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id A6F936B020C for ; Tue, 23 Mar 2021 11:12:51 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 706CD9077 for ; Tue, 23 Mar 2021 15:12:51 +0000 (UTC) X-FDA: 77951481342.32.6DF4098 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 6E97C200027D for ; Tue, 23 Mar 2021 15:12:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616512363; 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=BBrNnOv/McZM6LWQLKMPWqSfLeVDTkLLZJVsJZTyQog=; b=eOFTRPnDICj0n62VCvuevyiDHrthw8FpMFTpNXnv+ErlrXnDuJ6+FhdVHPuliJUOGXUuQR /pcuiic/hlR5Gan5t6A6N/t69L+bbbmlgTMquCho2eOzjfT5irqeS/7QXuCf8hdetK7R9l 4FP/pYf7gf2REpmPTQjw9TC3sEm0s38= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-291-dhXDfseSN_yCN9gfXzPFJQ-1; Tue, 23 Mar 2021 11:12:42 -0400 X-MC-Unique: dhXDfseSN_yCN9gfXzPFJQ-1 Received: by mail-qt1-f197.google.com with SMTP id t5so1407683qti.5 for ; Tue, 23 Mar 2021 08:12:42 -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=BBrNnOv/McZM6LWQLKMPWqSfLeVDTkLLZJVsJZTyQog=; b=QDAWDU0knIZpLacdjBO0mhhcKbcEa2ZTD8aUGAj2y+1A57KVQISqZBwgzmOkAIfMbU QMeqpQ5gkfSpO/vVs38jKJXNPRYOf46ZGy+1L0el2fOPSgnXqvyL9p6HrQ8t69RiV3Am UtoTxcWXnQrEn4f49WQKsCErdr+nkPMBrzu+va+K9dfLU+igRUOOWGjX5pYo6zgROzD4 CH2IfjFxOLU6VrZK4/lKxqkHbiLXAB0kdxWUayN5MqWup0xeZIYBsWm/leVfLQH8Xgbv K/7o/lTwep+aQWjyCZVKUaaEE7lXzR65xo4HmBsmLAhKwsrfSt6lN5lbiYsKDbxWawso KiKA== X-Gm-Message-State: AOAM530Rx/v8cgN5gCZ6PjrNdi3912Y7fxFO7Qk2AEa8qtcrMWcEx/yV yWzlYgz8QsO3DRM69bkhpPnND0j1XOdhwfIaiZcTptIufPkj9tX9/uF6hgPeJE1U4xMvx3+putX 1hdh/jScyLEQ= X-Received: by 2002:ae9:f80b:: with SMTP id x11mr5818789qkh.220.1616512361489; Tue, 23 Mar 2021 08:12:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIxKNqPmHIOGxOtkXSkKplsktvQrDyjO7VlhcNoVyxe4fINJlGw1PBoCbrWrDxb/a6STrC0Q== X-Received: by 2002:ae9:f80b:: with SMTP id x11mr5818753qkh.220.1616512361162; Tue, 23 Mar 2021 08:12:41 -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 a2sm11185972qtj.76.2021.03.23.08.12.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 08:12:40 -0700 (PDT) Date: Tue, 23 Mar 2021 11:12:38 -0400 From: Peter Xu To: Bui Quang Minh Cc: Mike Rapoport , Michal Hocko , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli Subject: Re: [PATCH] userfaultfd: Write protect when virtual memory range has no page table entry Message-ID: <20210323151238.GD6486@xz-x1> References: <20210319152428.52683-1-minhquangbui99@gmail.com> <20210323024803.GA3365@local> MIME-Version: 1.0 In-Reply-To: <20210323024803.GA3365@local> 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-Stat-Signature: dd1hmmmfcqxwdgdj56fo4puzgr1n3kn7 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6E97C200027D 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=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616512368-875278 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 Tue, Mar 23, 2021 at 09:48:03AM +0700, Bui Quang Minh wrote: > 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. > > Yes, you are right. I saw a patch from Peter to linux-man and saw that > > "When there is only UFFDIO_REGISTER_MODE_WP registered, the userspace > will not receive any message when a missing page is written" > > It's my mistake that I didn't look at the documentation carefully when playing > around. If there's a mistake, it's me forgetting to write the document when the feature landed.. :) But still I think you raised a good point, and I was also serious when proposing that UFFD_FEATURE_WP_UNALLOCATED idea, since indeed we had similar issue as QEMU live snapshot e.g. when the guest enabled kernel init_on_free, meanwhile virtio-balloon could have recycled the same zero page, then that zero page could got replaced with some garbage page when saving the snapshot, while we expect it to come back as strictly a zero page, since when the guest OS reuse this page it'll skip zeroing it assuming it's a zero page. QEMU plans to fix it using pre-faults as UFFDIO_COPY will complicate the live snapshot framework, but UFFD_FEATURE_WP_UNALLOCATED should be more efficient. It's just that we still needs to keep the old behavior. I'll see whether I can prepare a patch for it shortly, with some test case too. Thanks, -- Peter Xu