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 3A9B8C433DB for ; Thu, 7 Jan 2021 22:52:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C7E7235FA for ; Thu, 7 Jan 2021 22:52:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728264AbhAGWw0 (ORCPT ); Thu, 7 Jan 2021 17:52:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727669AbhAGWwY (ORCPT ); Thu, 7 Jan 2021 17:52:24 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4ADEEC0612F4 for ; Thu, 7 Jan 2021 14:51:44 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id o13so18539789lfr.3 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=mjOyo7oeX0S15nE1IhQ8/wDhunb3IJvQ+BktQI+rvMd83ZXvUryeoB6WAVU/eGR3jv nw08yz8FLEm8PiEkrsiJPleYwnuPochaHWhEH/D1T/eCeiU/gFl4lF9XSnblBmEpfwvM coP/mODeUCAiUAyeQ9BeEhla4ou52EAbGcYAXpVCobaGJBu8CzGpXHnjAZ4u/hjjDa0Z ZABZS2vH2Lo+jZJUU2jXwYWFHq7HpZVhUQWS5wR0sjmm5m27dkOVLTNV4lALyn509YzN ihrqT/WXd4FkLM5UKXI6xPyVVR5DU5n16mx5YocPaOF87fLEIME1rRIAGRobcVMcuGOo SayA== X-Gm-Message-State: AOAM530PBiQJYfUSriogvs8B24G5ecMN1AHgnJGqVswssjtxe5yd7ecB 9OypayXpfDjczucFCfrYeavl+Vk7a4XSgA== X-Google-Smtp-Source: ABdhPJx2qulEq4wq4fV8kqOmKqDcuNSzyhzimj5r0GVhwW8nf+Uu3kJ1bZQPvfRatPigKbFXi3J0tQ== X-Received: by 2002:a2e:87cb:: with SMTP id v11mr276920ljj.218.1610059902216; Thu, 07 Jan 2021 14:51:42 -0800 (PST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id s4sm1593726ljp.123.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-f51.google.com with SMTP id h205so18497893lfd.5 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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