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,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_RED 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 A8B73C433E0 for ; Thu, 7 Jan 2021 22:51:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3F57523601 for ; Thu, 7 Jan 2021 22:51:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3F57523601 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 941448D015A; Thu, 7 Jan 2021 17:51:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F26A8D0156; Thu, 7 Jan 2021 17:51:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76B2E8D015A; Thu, 7 Jan 2021 17:51:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 59FE18D0156 for ; Thu, 7 Jan 2021 17:51:45 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1D73E180AD80F for ; Thu, 7 Jan 2021 22:51:45 +0000 (UTC) X-FDA: 77680477770.04.fall02_480da87274ed Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id F0AD880137C1 for ; Thu, 7 Jan 2021 22:51:44 +0000 (UTC) X-HE-Tag: fall02_480da87274ed X-Filterd-Recvd-Size: 5838 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 22:51:44 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id m25so18366573lfc.11 for ; Thu, 07 Jan 2021 14:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MpUXPlOpjoaY/t+m2AK2xZLsPyG5FSaY9KMpLdS2dhw=; b=G4oJ39ti8dgcRqvI7baXd54HVqR6F0iRx/fnKM96EUoWqgYKtQCN07SCaol2E0qoZA 1/0qyVSNPbPjKiFYtyydwwn63S8AffyVbCftg3OOFVFN20qvxP36tMnvcmtcQcHudZJa XZ2BPp/sEsPoEEDpsVVoQUye8djTn0iPsEm0M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MpUXPlOpjoaY/t+m2AK2xZLsPyG5FSaY9KMpLdS2dhw=; b=NDhya+6IPBbGabVm8m18Xm/pzC5cxWviCUAw2Pv5S5hFBclwY+Z8lqKxSexlAvIRpm C98qfVeZuv9y/Z1oDTUfUfiZB7dB241/NUNW+1WOpLmUczcU9LWR6h+Z3Ji6dA/NPBhy pSChx4lt8vlfCqRAEymdIClRyvRSqMTPhHA68Q/Tpf4ee9/Zjt9WJXwPCht+Qoc+ni2e 4fDID8/qM6cVkhsQ1ycMkActfCEz6g4VCljdf1LN0ztn9NzTlH+AJW/TyFe6+/sWFJHH YKE4SJTYSF0+Nx3SVkcQgrYqgFqs40DiJq9ash3vmTVo+X8JaVJIgs8ZFLUFUUl402jM ktOw== X-Gm-Message-State: AOAM532Yc0t2+p6Do+HkBxGJohWdYEco+jefGZyOAtmCeMHRtBCa0XrP kwA9T0WGz1wGWZRC4racyYcFp5aNMmGlyA== X-Google-Smtp-Source: ABdhPJx7u+knkn1w4rKK3MVyJuMqv1WvGn46VJZKJQPlVibDod4P9RG8FHvVryGqZ/kbToY+X3hhUQ== X-Received: by 2002:a05:651c:118a:: with SMTP id w10mr268953ljo.13.1610059902170; Thu, 07 Jan 2021 14:51:42 -0800 (PST) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id f21sm1460323lfe.6.2021.01.07.14.51.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 14:51:41 -0800 (PST) Received: by mail-lf1-f42.google.com with SMTP id h22so18568735lfu.2 for ; Thu, 07 Jan 2021 14:51:40 -0800 (PST) X-Received: by 2002:a2e:b4af:: with SMTP id q15mr255547ljm.507.1610059900270; Thu, 07 Jan 2021 14:51:40 -0800 (PST) MIME-Version: 1.0 References: <20210107200402.31095-1-aarcange@redhat.com> <20210107200402.31095-3-aarcange@redhat.com> In-Reply-To: From: Linus Torvalds Date: Thu, 7 Jan 2021 14:51:24 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] mm: soft_dirty: userfaultfd: introduce wrprotect_tlb_flush_pending To: Andrea Arcangeli Cc: Linux-MM , Linux Kernel Mailing List , Yu Zhao , Andy Lutomirski , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Peter Zijlstra , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Oleg Nesterov , Jann Horn , Kees Cook , John Hubbard , Leon Romanovsky , Jason Gunthorpe , Jan Kara , Kirill Tkhai Content-Type: text/plain; charset="UTF-8" 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 Thu, Jan 7, 2021 at 2:42 PM Linus Torvalds wrote: > > But I thought we agreed earlier that that is a bug. And I thought the > softdirty code already got it for writing. Ho humm. I had obviously not looked very much at that code. I had done a quick git grep, but now that I look closer, it *does* get the mmap_sem for writing, but only for that VM_SOFTDIRTY bit clearing, and then it does a mmap_write_downgrade(). So that's why I had looked more at the UFFD code, because that one was the one I was aware of doing this all with just the read lock. I _thought_ the softdirty code already took the write lock and wouldn't race with page faults. But I had missed that write_downgrade. So yeah, this code has the same issue. Anyway, the fix is - I think - the same I outlined earlier when I was talking about UFFD: take the thing for writing, so that you can't race. The alternate fix remains "make sure we always flush the TLB before releasing the page table lock, and make COW do the copy under the page table lock". But I really would prefer to just have this code follow all the usual rules, and if it does a write protect, then it should take the mmap_sem for writing. Why is that very simple rule so bad? (And see my unrelated but incidental note on it being a good idea to try to minimize latency by making surfe we don't do any IO under the mmap lock - whether held for reading _or_ writing. Because I do think we can improve in that area, if you have some good test-case). Linus