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=-5.8 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 73672C43460 for ; Mon, 12 Apr 2021 21:54:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 05C1A6128E for ; Mon, 12 Apr 2021 21:54:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05C1A6128E 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 845366B006C; Mon, 12 Apr 2021 17:54:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CE8F6B006E; Mon, 12 Apr 2021 17:54:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F94A6B0070; Mon, 12 Apr 2021 17:54:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 3C8ED6B006C for ; Mon, 12 Apr 2021 17:54:46 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EEDF41E04 for ; Mon, 12 Apr 2021 21:54:45 +0000 (UTC) X-FDA: 78025070130.16.A3B7107 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 3CA42C0007D4 for ; Mon, 12 Apr 2021 21:54:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618264485; 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=rSg/4g7S1VAs0BEe21c6JFZm2CbvqXRaPJMkscjjUzQ=; b=jJB/kV1kcaBNMgd0uDdH4MEbhaA368eRC1dg6i1M8z7z61uPttwzcbRCD8wgJfflxdR2xg AFuADfAkxovbhw5VxWdtRrN40+6zyFp8HU/3h7bI5OjmPzk81Mlkung0bM2e5fOP3t6xko EUymEesfA5FxNjoxJ8HUUl2w3B2bRA0= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-531-fvK4URs6Pt2hE0cWExgHMQ-1; Mon, 12 Apr 2021 17:54:42 -0400 X-MC-Unique: fvK4URs6Pt2hE0cWExgHMQ-1 Received: by mail-qk1-f198.google.com with SMTP id b127so9918879qkf.19 for ; Mon, 12 Apr 2021 14:54: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=rSg/4g7S1VAs0BEe21c6JFZm2CbvqXRaPJMkscjjUzQ=; b=IGRvsicUzXP+N1WHx2sBb7rq3Jwd6yJwY+uIlXFBV7DZb7EquwzKlFFKD2mprUorbg 4zm8oAMPy5ty/6UwG0+YnDbzkby6MbjDPNdxrhRO2aM+ROA3wWFfSlP8QDXLRcoWZBFS sKLdq+dFNECiKMBP98HWgV07PM2bKHyqmeXVpZ+QV6qkEOUBVVyJWqA9AKIII5af6Iab cjWpgjSshCzdfVnZWEXFAIP/UQc/1gyr/Oh8Tfa8aP7ODIATDRfSFz10ps1LCzVqpV3j +sKDUvvQUYm7Ci8hjBPDG04NxUJY40nIWK9QCFf89yW8r8miOFY8Sv/RqZi5UcCW/B79 16YA== X-Gm-Message-State: AOAM531b50BqPBNVt+rswuUjWgidX0vrlKfplZWXAWIL3mCjYXiZMRkS 7ga8IJVAGs3PrgwUvsJHCSOknwq4r/SHdjfyttrW58r37jw6auJM18IxC2XEiCK3m5IzPBznHEx r23QALEddub0= X-Received: by 2002:a05:6214:14b4:: with SMTP id bo20mr4943808qvb.20.1618264482042; Mon, 12 Apr 2021 14:54:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbD4DC7OMtAMwjp3Zq2ZGY5AAvdzECr9OQOYMWUawBpI5JNBVDfUwjpTZGyULdEUCkWeV3/g== X-Received: by 2002:a05:6214:14b4:: with SMTP id bo20mr4943769qvb.20.1618264481785; Mon, 12 Apr 2021 14:54:41 -0700 (PDT) Received: from xz-x1 (bras-base-toroon474qw-grc-88-174-93-75-154.dsl.bell.ca. [174.93.75.154]) by smtp.gmail.com with ESMTPSA id z18sm3501170qkg.42.2021.04.12.14.54.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Apr 2021 14:54:40 -0700 (PDT) Date: Mon, 12 Apr 2021 17:54:37 -0400 From: Peter Xu To: Hugh Dickins Cc: Axel Rasmussen , Alexander Viro , Andrea Arcangeli , Andrew Morton , Jerome Glisse , Joe Perches , Lokesh Gidra , Mike Rapoport , Shaohua Li , Shuah Khan , Stephen Rothwell , Wang Qing , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Brian Geffon , Cannon Matthews , "Dr . David Alan Gilbert" , David Rientjes , Michel Lespinasse , Mina Almasry , Oliver Upton Subject: Re: [PATCH v4] userfaultfd/shmem: fix MCOPY_ATOMIC_CONTINUE behavior Message-ID: <20210412215437.GA1001332@xz-x1> References: <20210401183701.1774159-1-axelrasmussen@google.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: rspam05 X-Rspamd-Queue-Id: 3CA42C0007D4 X-Stat-Signature: zpzxrjxk7maznn9afre53rjbgz4gtxfh Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf22; 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: 1618264482-504662 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: Hi, Hugh, On Tue, Apr 06, 2021 at 11:14:30PM -0700, Hugh Dickins wrote: > > +static int mcopy_atomic_install_ptes(struct mm_struct *dst_mm, pmd_t *dst_pmd, > > + struct vm_area_struct *dst_vma, > > + unsigned long dst_addr, struct page *page, > > + enum mcopy_atomic_mode mode, bool wp_copy) > > +{ [...] > > + if (writable) { > > + _dst_pte = pte_mkdirty(_dst_pte); > > + if (wp_copy) > > + _dst_pte = pte_mkuffd_wp(_dst_pte); > > + else > > + _dst_pte = pte_mkwrite(_dst_pte); > > + } else if (vm_shared) { > > + /* > > + * Since we didn't pte_mkdirty(), mark the page dirty or it > > + * could be freed from under us. We could do this > > + * unconditionally, but doing it only if !writable is faster. > > + */ > > + set_page_dirty(page); > > I do not remember why Andrea or I preferred set_page_dirty() here to > pte_mkdirty(); but I suppose there might somewhere be a BUG_ON(pte_dirty) > which this would avoid. Risky to change it, though it does look odd. Is any of the possible BUG_ON(pte_dirty) going to trigger because the pte has write bit cleared? That's one question I was not very sure, e.g., whether one pte is allowed to be "dirty" if it's not writable. To me it's okay, it's actually very suitable for UFFDIO_COPY case, where it is definitely dirty data (so we must never drop it) even if it's installed as RO, however to achieve that we can still set the dirty on the page rather than the pte as what we do here. It's just a bit awkward as you said. Meanwhile today I just noticed this in arm64 code: static inline pte_t pte_wrprotect(pte_t pte) { /* * If hardware-dirty (PTE_WRITE/DBM bit set and PTE_RDONLY * clear), set the PTE_DIRTY bit. */ if (pte_hw_dirty(pte)) pte = pte_mkdirty(pte); pte = clear_pte_bit(pte, __pgprot(PTE_WRITE)); pte = set_pte_bit(pte, __pgprot(PTE_RDONLY)); return pte; } So arm64 will explicitly set the dirty bit (from the HW dirty bit) when wr-protect. It seems to prove that at least for arm64 it's very valid to have !write && dirty pte. Thanks, -- Peter Xu