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=-4.6 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,URIBL_BLOCKED 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 48FE8C2D0A8 for ; Mon, 28 Sep 2020 17:23:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE0612100A for ; Mon, 28 Sep 2020 17:23:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="K6kOcWw7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE0612100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DE5466B0068; Mon, 28 Sep 2020 13:23:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D966A6B0087; Mon, 28 Sep 2020 13:23:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C849E6B0089; Mon, 28 Sep 2020 13:23:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id AF0E56B0068 for ; Mon, 28 Sep 2020 13:23:02 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 786651DE9 for ; Mon, 28 Sep 2020 17:23:02 +0000 (UTC) X-FDA: 77313140604.28.stem69_09184eb27183 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 58EBA6C04 for ; Mon, 28 Sep 2020 17:23:02 +0000 (UTC) X-HE-Tag: stem69_09184eb27183 X-Filterd-Recvd-Size: 5575 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Sep 2020 17:23:01 +0000 (UTC) Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601313781; 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=1LTS8PVfmK/f/9X7OPUUAt2g8tDoLOrDZ8lScUVnhFM=; b=K6kOcWw7MomlJksFXa+uKar7lBwa6alwZMvfiKdm9Jr/m2iRf+E6M3hfJZPRycECmAMyXu +P1ch866sD1bMDnIn6T3vTh/y7XEU4aPwNq3BZK4FiHliAGeyV18/MavPvCjSjjbYROYPr +uMHjWYTy0mnX1mgmpl8Nj5ixovHWQQ= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-438-t8QgyJ-SPt-u_SO1OR8KIg-1; Mon, 28 Sep 2020 13:22:59 -0400 X-MC-Unique: t8QgyJ-SPt-u_SO1OR8KIg-1 Received: by mail-qk1-f200.google.com with SMTP id 205so1052453qkd.2 for ; Mon, 28 Sep 2020 10:22:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1LTS8PVfmK/f/9X7OPUUAt2g8tDoLOrDZ8lScUVnhFM=; b=gvQ7Vrd0mP+Os/EErdPDvFy9V8uOtL6PAQtCs1E8rk00qqvXM5lsEEsIae4mR73kG/ sP6zuKeZ659y8CIKTWIbwaWm0h+BAnORRQmkITmpNoXoPdOE9yJl8RYXiVMvIJEX6HMu FyFie26YQ1u5pgXoUZGLRjMb7+zzFmxLp1GKPP1hcbW9DK7L5+KkJBjzbWnYbsxmsV/p rM8nMRvZzCQzyTErz624uEl2EfJDLti3tJN+ZsaQteyM6/a8HDxx/571beqVzzdT17eU 8InuWmOf70zKKVyfd5KlM1zdGDVZZZKcr7dV7zz15JrKPIus/2JwpBVCIJPQMT5KYHuT +Vtw== X-Gm-Message-State: AOAM532wuY5yrTSzYQTRe05JLMAVsOzOs+Z1ob/g4eHDLK3SLufxJFi+ rlfKFnVwfKEzDfT5C7gswbkOFlQ8ctDz0QQMmoJjfC+C0e3AZY1L6ZqNwd2v3Jz5pAlsVRmdINZ jqrXz8LzECNU= X-Received: by 2002:a37:7687:: with SMTP id r129mr515683qkc.264.1601313778686; Mon, 28 Sep 2020 10:22:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwuXmEuI87fdrdB0w8cRZk9cGfXhSuARqBzz4HNUwKmE2Gkx1CiZ+mjwn/YiJGYRY+wZCCNRw== X-Received: by 2002:a37:7687:: with SMTP id r129mr515652qkc.264.1601313778371; Mon, 28 Sep 2020 10:22:58 -0700 (PDT) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-11-70-53-122-15.dsl.bell.ca. [70.53.122.15]) by smtp.gmail.com with ESMTPSA id e7sm2028873qtk.17.2020.09.28.10.22.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2020 10:22:57 -0700 (PDT) Date: Mon, 28 Sep 2020 13:22:56 -0400 From: Peter Xu To: Linus Torvalds Cc: Jason Gunthorpe , Leon Romanovsky , John Hubbard , Linux-MM , Linux Kernel Mailing List , Andrew Morton , Jan Kara , Michal Hocko , Kirill Tkhai , Kirill Shutemov , Hugh Dickins , Christoph Hellwig , Andrea Arcangeli , Oleg Nesterov , Jann Horn Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned Message-ID: <20200928172256.GB59869@xz-x1> References: <20200926004136.GJ9916@ziepe.ca> <20200927062337.GE2280698@unreal> <20200928124937.GN9916@ziepe.ca> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Mon, Sep 28, 2020 at 09:17:09AM -0700, Linus Torvalds wrote: > On Mon, Sep 28, 2020 at 5:49 AM Jason Gunthorpe wrote: > > > > Not seeing an obvious option besides adding a smp_mb() before > > page_maybe_dma_pinned() as Peter once suggested. > > That is going to be prohibitively expensive - needing it for each pte > whether it's pinned or not. > > I really think the better option is a "don't do that then". This has > _never_ worked before either except by pure luck. Yes... Actually I am also thinking about the complete solution to cover read-only fast-gups too, but now I start to doubt this, at least for the fork() path. E.g. if we'd finally like to use pte_protnone() to replace the current pte_wrprotect(), we'll be able to also block the read gups, but we'll suffer the same degradation on normal fork()s, or even more. Seems unacceptable. The other question is, whether we should emphasize and document somewhere that MADV_DONTFORK is still (and should always be) the preferred way, because changes like this series can potentially encourage the other way. -- Peter Xu