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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 E6507C433E0 for ; Sun, 17 Jan 2021 07:32:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6986623117 for ; Sun, 17 Jan 2021 07:32:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6986623117 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5FD1F8D0216; Sun, 17 Jan 2021 02:32:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5ADFC8D01D5; Sun, 17 Jan 2021 02:32:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49B478D0216; Sun, 17 Jan 2021 02:32:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 31EAA8D01D5 for ; Sun, 17 Jan 2021 02:32:28 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E3FCB365A for ; Sun, 17 Jan 2021 07:32:27 +0000 (UTC) X-FDA: 77714449134.05.bat07_08142642753e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id C0F711801DC08 for ; Sun, 17 Jan 2021 07:32:27 +0000 (UTC) X-HE-Tag: bat07_08142642753e X-Filterd-Recvd-Size: 7178 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Sun, 17 Jan 2021 07:32:27 +0000 (UTC) Received: by mail-pf1-f174.google.com with SMTP id h186so8306198pfe.0 for ; Sat, 16 Jan 2021 23:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sBCeRfGu3HpuvJkTgZps1o7i3Djrk1XekJ+FW6NcBqc=; b=dEmqzX6MzUfLYobSu1aZQcbPqdtr+PoobwUvgSutjIUk5jYrWmY96/Ar8lCz7v/N/H XAflD5Fs45bb/eZ8Gfw+A0bNu20iXGdf9QqcAEJwb+joLWMuroZ8znoL+qaTiO9rmm9C J0o+Q7lXt5IDZUvS7tBRpg2tAa2UHXwxfjDrrOlvsK2gS8KXJ5B3tpwZ00dgSc7fsYVn DaZZVk+OvWl6ofIgd7oy1s6QgOPAHiVMFxmSYatvO5PDRtz/PZHdBFuP0SMgxN9Lv6Go wQL80mwYLSU/3XFjudprp5/OFNS6GRHahRd+OYx+j7ju3x9adYm48ZnYJZYStt3cvuk5 bBMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sBCeRfGu3HpuvJkTgZps1o7i3Djrk1XekJ+FW6NcBqc=; b=qkF3Th1ctP9oYX1mTz2kn/Wx9J9I411RTWFWgaM5ZJafPoOxw4kxKNfj3hqKW3lt8p RrHbmE+6JUtq9mrPYnJVYeBpI+9OTRkHjcMSBXkGy0sh+iwOLoaiBIkVn7FsqkAMA1M3 /etiAVSnyE0PNPjOKxAfKgPJTB8flBPLL0kzwI4BbvW8GWiDpaaABXLQqzo74OS4fW+I I4PuC1uYXxq+GKZgELk2IWG+BDGSip2m2/Nx0NgtRZB6gKmWU/qJgD+xrjGx9GZRF4to grimJZ6OSly9b+EbTczAc9heRDNUqzLzqx63twuRvP2NukkPoTHvPFdilM53xmNhX2k8 iRbQ== X-Gm-Message-State: AOAM531sg/3xXUlqsv+JtzWkUkV0pfEfk7OqwifCcp4CbLhEqGu0D55Y EGal2fWDGgROv4bMaML9S9A= X-Google-Smtp-Source: ABdhPJz4HmBhYzLyT3UJ9TwbKiLmgP2cMQv0LvOHakHdeqzb/EXgR825ZilvQT0XrXc/3UZ/1K+MBw== X-Received: by 2002:a05:6a00:2296:b029:1b6:6972:2f2a with SMTP id f22-20020a056a002296b02901b669722f2amr3457483pfe.69.1610868745983; Sat, 16 Jan 2021 23:32:25 -0800 (PST) Received: from [192.168.88.245] (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id u1sm12207007pjr.51.2021.01.16.23.32.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jan 2021 23:32:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect From: Nadav Amit In-Reply-To: Date: Sat, 16 Jan 2021 23:32:22 -0800 Cc: Will Deacon , Laurent Dufour , Peter Zijlstra , Vinayak Menon , Linus Torvalds , Andy Lutomirski , Peter Xu , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , surenb@google.com, Mel Gorman Content-Transfer-Encoding: quoted-printable Message-Id: <85DAADF4-2537-40BD-8580-A57C201FF5F3@gmail.com> References: <20210105153727.GK3040@hirez.programming.kicks-ass.net> <0201238b-e716-2a3c-e9ea-d5294ff77525@linux.vnet.ibm.com> <2C7AE23B-ACA3-4D55-A907-AF781C5608F0@gmail.com> <20210112214337.GA10434@willie-the-truck> To: Yu Zhao X-Mailer: Apple Mail (2.3608.120.23.2.4) 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 Jan 16, 2021, at 8:41 PM, Yu Zhao wrote: >=20 > On Tue, Jan 12, 2021 at 09:43:38PM +0000, Will Deacon wrote: >> On Tue, Jan 12, 2021 at 12:38:34PM -0800, Nadav Amit wrote: >>>> On Jan 12, 2021, at 11:56 AM, Yu Zhao wrote: >>>> On Tue, Jan 12, 2021 at 11:15:43AM -0800, Nadav Amit wrote: >>>>> I will send an RFC soon for per-table deferred TLB flushes = tracking. >>>>> The basic idea is to save a generation in the page-struct that = tracks >>>>> when deferred PTE change took place, and track whenever a TLB = flush >>>>> completed. In addition, other users - such as mprotect - would use >>>>> the tlb_gather interface. >>>>>=20 >>>>> Unfortunately, due to limited space in page-struct this would only >>>>> be possible for 64-bit (and my implementation is only for x86-64). >>>>=20 >>>> I don't want to discourage you but I don't think this would end up >>>> well. PPC doesn't necessarily follow one-page-struct-per-table = rule, >>>> and I've run into problems with this before while trying to do >>>> something similar. >>>=20 >>> Discourage, discourage. Better now than later. >>>=20 >>> It will be relatively easy to extend the scheme to be per-VMA = instead of >>> per-table for architectures that prefer it this way. It does require >>> TLB-generation tracking though, which Andy only implemented for x86, = so I >>> will focus on x86-64 right now. >>=20 >> Can you remind me of what we're missing on arm64 in this area, = please? I'm >> happy to help get this up and running once you have something I can = build >> on. >=20 > I noticed arm/arm64 don't support ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH. > Would it be something worth pursuing? Arm has been using mm_cpumask, > so it might not be too difficult I guess? [ +Mel Gorman who implemented ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH ] IIUC, there are at least two bugs in x86 implementation. First, there is a missing memory barrier in tlbbatch_add_mm() between inc_mm_tlb_gen() and the read of mm_cpumask(). Second, try_to_unmap_flush() clears flush_required after flushing. = Another thread can call set_tlb_ubc_flush_pending() after the flush and before flush_required is cleared, and the indication that a TLB flush is = pending can be lost. I am working on addressing these issues among others, but, as you = already saw, I am a bit slow. On a different but related topic: Another thing that I noticed that Arm = does not do is batching TLB flushes across VMAs. Since Arm does not have its = own tlb_end_vma(), it uses the default tlb_end_vma(), which flushes each VMA separately. Peter Zijlstra=E2=80=99s comment says that there are = advantages in flushing each VMA separately, but I am not sure it is better or = intentional (especially since x86 does not do so). I am trying to remove the arch-specific tlb_end_vma() and have a config option to control this behavior. Again, sorry for being slow. I hope to send an RFC soon.