Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp261145pxu; Tue, 5 Jan 2021 10:08:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJymNVxYtyEmbT+wuGmwvIQScLUplQnIXzTlPL5xAQTfKY2k/+zANOawAk5pAs+yLgQ6jjic X-Received: by 2002:aa7:ce94:: with SMTP id y20mr943346edv.361.1609870106967; Tue, 05 Jan 2021 10:08:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609870106; cv=none; d=google.com; s=arc-20160816; b=lEVgy3kBnIyRH7xuL65GK1PQmxeUEcLsADQTwODbwUf2L/Qufrc3EYOzD/hn2Yie1J VxESgLufuLCqiXpvh4Pk6+yz0FkPJaT42CB9bCnfCWkQ/4ytiHord6fZ2hGSi6I5SpSZ lkMuZGghn3aHKB8lUNXccgf+DeKqArftEQOvvPeQ5G3l4WRE6MUwyujkei48Bs2vNWcK EmFM4yxXIEriemGW7eqFk7o9EQnqL+6dQs/lHwCpDarH2ZBZFyQZN+lwwYhreyA6kL/J AMId1Upg9tJFnOErvqRy+VEW/kR/f/BWFoM1nyyHV5jZ3AJcaahWG+EoxpdaqeWzfTgI jPbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=tjij9xYMf6Y62hwh1O7GXaGMsMvqywzvQeHIvJ4Lc+s=; b=aajt3pzbK+XtCQUe/yrA5gKT1eG4LjvvDA2T5qYDB9H6fTQVpMfciZhDYTZFmvFCHv VnX0u+ulnBFPg8mNQEg7bIXGSQpnca64k09eDENP9KWl4NyiFOMicshiPq4bgWu05/wU YItAaSEFOK7hbMY04jR2mTJlf7zRH1D0xfRBE7HueI2ePNf0+TElq0JnHsSiD9hhJ6ei AnJAkco71B4mwkInkX3MMGek7huDQfWhX2avneWtc0NdLdqoob3EmZ84WaNPk1ZfoAFa wYtEEZ2Xd0SCUzQ7vTiiUZrnWdJ6dCZxB3fbh0QUrk2/pecIvziwCUJ7hAqmLmzJoGzV TBjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SbEjl9w6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s4si195392edy.281.2021.01.05.10.08.03; Tue, 05 Jan 2021 10:08:26 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SbEjl9w6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730030AbhAESFY (ORCPT + 99 others); Tue, 5 Jan 2021 13:05:24 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:37291 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727404AbhAESFX (ORCPT ); Tue, 5 Jan 2021 13:05:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609869837; 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=tjij9xYMf6Y62hwh1O7GXaGMsMvqywzvQeHIvJ4Lc+s=; b=SbEjl9w6eEmY+VCdEaVzFoyufe9vXicPhHXGdKGW23mX2iEwR8ouiYH9mJgle5X909JPoa SJtINKopGqxvo2LP9UE65hRE080+p6rBqHIFxU1jkwQCmPJyF2QaWDWmj5XhmYhPpT4X8N kccAuO7Xkk2flaIX+yudZBXxOlbTEuM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-Xh2GoTdcN1qQiXdJXLzRog-1; Tue, 05 Jan 2021 13:03:53 -0500 X-MC-Unique: Xh2GoTdcN1qQiXdJXLzRog-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0B25DA0CA0; Tue, 5 Jan 2021 18:03:52 +0000 (UTC) Received: from mail (ovpn-112-76.rdu2.redhat.com [10.10.112.76]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D6DBB5E1B5; Tue, 5 Jan 2021 18:03:48 +0000 (UTC) Date: Tue, 5 Jan 2021 13:03:48 -0500 From: Andrea Arcangeli To: Peter Zijlstra Cc: Linus Torvalds , Andy Lutomirski , Peter Xu , Nadav Amit , Yu Zhao , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Will Deacon Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: References: <9E301C7C-882A-4E0F-8D6D-1170E792065A@gmail.com> <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> <20201221223041.GL6640@xz-x1> <20210105153727.GK3040@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210105153727.GK3040@hirez.programming.kicks-ass.net> User-Agent: Mutt/2.0.4 (2020-12-30) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 05, 2021 at 04:37:27PM +0100, Peter Zijlstra wrote: > (your other email clarified this point; the COW needs to copy while > holding the PTL and we need TLBI under PTL if we're to change this) The COW doesn't need to hold the PT lock, the TLBI broadcast doesn't need to be delivered under PT lock either. Simply there need to be a TLBI broadcast before the copy. The patch I sent here https://lkml.kernel.org/r/X+QLr1WmGXMs33Ld@redhat.com that needs to be cleaned up with some abstraction and better commentary also misses a smp_mb() in the case flush_tlb_page is not called, but that's a small detail. > And I'm thinking the speculative page fault series steps right into all > this, it fundamentally avoids mmap_sem and entirely relies on the PTL. I thought about that but that only applies to some kind of "anon" page fault. Here the problem isn't just the page fault, the problem is not to regress clear_refs to block on page fault I/O, and all MAP_PRIVATE/MAP_SHARED filebacked faults bitting the disk to read /usr/ will still prevent clear_refs from running (and the other way around) if it has to take the mmap_sem for writing. I don't look at the speculative page fault for a while but last I checked there was nothing there that can tame the above major regression from CPU speed to disk I/O speed that would be inflicted on both clear_refs on huge mm and on uffd-wp. Thanks, Andrea