Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 2 Mar 2021 17:13:14 -0500
From:   Peter Xu <peterx@redhat.com>
To:     Nadav Amit <nadav.amit@gmail.com>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Nadav Amit <namit@vmware.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Yu Zhao <yuzhao@google.com>, Andy Lutomirski <luto@kernel.org>,
        Pavel Emelyanov <xemul@openvz.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>,
        Minchan Kim <minchan@kernel.org>,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC PATCH v2 0/2] mm: fix races due to deferred TLB flushes
Message-ID: <20210302221314.GR397383@xz-x1>
References: <20201225092529.3228466-1-namit@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20201225092529.3228466-1-namit@vmware.com>
Precedence: bulk

On Fri, Dec 25, 2020 at 01:25:27AM -0800, Nadav Amit wrote:
> From: Nadav Amit <namit@vmware.com>
> 
> This patch-set went from v1 to RFCv2, as there is still an ongoing
> discussion regarding the way of solving the recently found races due to
> deferred TLB flushes. These patches are only sent for reference for now,
> and can be applied later if no better solution is taken.
> 
> In a nutshell, write-protecting PTEs with deferred TLB flushes was mostly
> performed while holding mmap_lock for write. This prevented concurrent
> page-fault handler invocations from mistakenly assuming that a page is
> write-protected when in fact, due to the deferred TLB flush, other CPU
> could still write to the page. Such a write can cause a memory
> corruption if it takes place after the page was copied (in
> cow_user_page()), and before the PTE was flushed (by wp_page_copy()).
> 
> However, the userfaultfd and soft-dirty mechanisms did not take
> mmap_lock for write, but only for read, which made such races possible.
> Since commit 09854ba94c6a ("mm: do_wp_page() simplification") these
> races became more likely to take place as non-COW'd pages are more
> likely to be COW'd instead of being reused. Both of the races that
> these patches are intended to resolve were produced on v5.10.
> 
> To avoid the performance overhead some alternative solutions that do not
> require to acquire mmap_lock for write were proposed, specifically for
> userfaultfd. So far no better solution that can be backported was
> proposed for the soft-dirty case.
> 
> v1->RFCv2:
> - Better (i.e., correct) description of the userfaultfd buggy case [Yu]
> - Patch for the soft-dirty case

Nadav,

Do you plan to post a new version to fix the tlb corrupt issue that this series
wanted to solve?

Thanks,

-- 
Peter Xu