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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 C9639C433DB for ; Thu, 24 Dec 2020 04:03:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9DB4322AAA for ; Thu, 24 Dec 2020 04:03:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727114AbgLXECp (ORCPT ); Wed, 23 Dec 2020 23:02:45 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:49395 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725846AbgLXECo (ORCPT ); Wed, 23 Dec 2020 23:02:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608782477; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HaM5vqeoz7uyCdtjEZGPvgmfZfkHGEzfapMlshdVV/I=; b=FfPUsKuGuc24WODhykC+7G9ARn1z00ZegTcR7zRH1X7BhleL8iFJLjOp8NUlZlJ6QbYi5L mv+ETBBUwlfH5vMK6+QKLat3EcBYK87U6p9juOYjKxVRGsZvyUezM3DhSFwb5u1xEqnKd8 m0mNM13RWzGw1+0KFYbRZgCZHQWziSc= 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-368-UCmXtoJCMlmYJsHL39CugA-1; Wed, 23 Dec 2020 23:01:15 -0500 X-MC-Unique: UCmXtoJCMlmYJsHL39CugA-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 BB646801AAF; Thu, 24 Dec 2020 04:01:13 +0000 (UTC) Received: from mail (ovpn-112-5.rdu2.redhat.com [10.10.112.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 232995F9B8; Thu, 24 Dec 2020 04:01:10 +0000 (UTC) Date: Wed, 23 Dec 2020 23:01:09 -0500 From: Andrea Arcangeli To: Yu Zhao Cc: Nadav Amit , Andy Lutomirski , Andy Lutomirski , Linus Torvalds , Peter Xu , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Will Deacon , Peter Zijlstra Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: References: <3A6A1049-24C6-4B2D-8C59-21B549F742B4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0.3 (2020-12-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: > > I think there are other cases in which Andy’s concern is relevant > > (MADV_PAGEOUT). I didn't try to figure how it would help MADV_PAGEOUT. MADV_PAGEOUT sounds cool feature, but maybe it'd need a way to flush the invalidates out and a take a static key to enable the buildup of those ranges? I wouldn't like to slow down the fast paths even for MADV_PAGEOUT, and the same applies to uffd-wp and softdirty in fact. On Wed, Dec 23, 2020 at 08:34:00PM -0700, Yu Zhao wrote: > That patch only demonstrate a rough idea and I should have been > elaborate: if we ever decide to go that direction, we only need to > worry about "jumping through hoops", because the final patch (set) > I have in mind would not only have the build time optimization Andrea > suggested but also include runtime optimizations like skipping > do_swap_page() path and (!PageAnon() || page_mapcount > 1). Rest > assured, the performance impact on do_wp_page() from occasionally an > additional TLB flush on top of a page copy is negligible. Agreed, I just posted something in that direction. Feel free to refactor it, it's just a tentative implementation to show something that may deliver all the performance we need in all cases involved without slowing down the fast paths of non-uffd and non-softdirty (well 1 branch). > On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: > > Perhaps holding some small bitmap based on part of the deferred flushed > > pages (e.g., bits 12-17 of the address or some other kind of a single > > hash-function bloom-filter) would be more performant to avoid (most) The concern here aren't only the page faults having to run the bloom filter, but how to manage the RAM storage pointed by the bloomfilter or whatever index into the storage, which would slowdown mprotect. Granted that mprotect is slow to begin with, but the idea we can't make it any slower to make MADV_PAGEOUT or uffd-wp or clear_refs run faster since it's too important and too frequent in comparison. Just to restrict the potential false positive IPI caused by page_count inevitable inaccuracies to uffd-wp and softdirty runtimes, a simple check on vm_flags should be enough. Thanks, Andrea