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=-3.9 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 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 2AC51C55178 for ; Mon, 26 Oct 2020 14:16:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7963121655 for ; Mon, 26 Oct 2020 14:16:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="MocRZOBq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7963121655 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 70D496B0062; Mon, 26 Oct 2020 10:16:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BD096B006C; Mon, 26 Oct 2020 10:16:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55BB46B006E; Mon, 26 Oct 2020 10:16:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id 25DE66B0062 for ; Mon, 26 Oct 2020 10:16:07 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9D508824999B for ; Mon, 26 Oct 2020 14:16:06 +0000 (UTC) X-FDA: 77414275932.06.ducks21_4f0a5cf27274 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id B1D681003E4DF for ; Mon, 26 Oct 2020 14:16:05 +0000 (UTC) X-HE-Tag: ducks21_4f0a5cf27274 X-Filterd-Recvd-Size: 5902 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Mon, 26 Oct 2020 14:16:05 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id x20so8405924qkn.1 for ; Mon, 26 Oct 2020 07:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3S2YjeCUC6K3doI4vgMQKoCwvJ4YN6LMw0KanLSj+uM=; b=MocRZOBqXvmKFTBQqlf9654tnqlf+n6zq+i2QdNLLQNEIAKlRxznKNH8lCVuCZXtx8 sL2hKpGdKOCK17bDT9PJq98n7qUnhsRxnYoL99XDVZ6GR99eNglEwr2LPb973O7RQ7HA pDW4sDBWyUQViJzK19iQsGqbK+MeQAGCD5TQEeKrBoKzCOYX/duYkiXTcQ4Qp8ccSABs Hftqzs+se0kaaq/6hY4MO1EHYC4oBnMYtT0YdyYt/VzKZq3XOZwc/e29IfN7g/5xfmSM QqCOBeeAbUr2ljY3/WF8B6umAyrwtt7+dYB8AO4wemgwHV5cww4O71ZknMmTdweIplAH m9wQ== 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=3S2YjeCUC6K3doI4vgMQKoCwvJ4YN6LMw0KanLSj+uM=; b=C7VVBljBBESM0AkgqKeCQamQn8jZcAtTezK7b+stjTFfPDOIdirp8X6J5UVi2QOgRK RlRdSnuQoE3zE3f1TycXh16u1II+kGSmKH9sokD/h6uIpu8nklHXTo3gxygSB5acJRdg LIeQetlo82bop2VhLZjY//g3n/HQGIrDysbRFZAAe0wYoBuyAX6LwajhheGeiUzNUGkx KYB0DgK7RgtRs3II0yQiW+kxh8VmonEzg2bO1kMRtcGvRWb8EYgFbg3lvgdvaouHU7Ae Jcm/QOZ8ZNyVH14WSoIQ+gX04+FPXgQ1UzJnNJ7bloOaOONJx8AiwbdOnN+cm8Qwng7r KvPQ== X-Gm-Message-State: AOAM530EetmNzcjiv3CW9wF08vnt/t7tl9y1clrNYuLLsA68uo3tkNIJ tC8rm7dIotd1FQn2RUNbYEoHdg== X-Google-Smtp-Source: ABdhPJyf953+FiRgW2dasVQsjm4zhSEzqYl6uwWT9W1zEpP8TS/DVtOK2Vqx2OZ03E5I04lE/XNsLg== X-Received: by 2002:a05:620a:849:: with SMTP id u9mr17366693qku.419.1603721762676; Mon, 26 Oct 2020 07:16:02 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id y77sm6331920qkb.57.2020.10.26.07.16.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 07:16:01 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kX3I1-008TP8-5d; Mon, 26 Oct 2020 11:16:01 -0300 Date: Mon, 26 Oct 2020 11:16:01 -0300 From: Jason Gunthorpe To: Matthew Wilcox Cc: John Hubbard , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , David Rientjes , Andrea Arcangeli , Kees Cook , Will Drewry , "Edgecombe, Rick P" , "Kleen, Andi" , Liran Alon , Mike Rapoport , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [RFCv2 08/16] KVM: Use GUP instead of copy_from/to_user() to access guest memory Message-ID: <20201026141601.GT36674@ziepe.ca> References: <20201020061859.18385-1-kirill.shutemov@linux.intel.com> <20201020061859.18385-9-kirill.shutemov@linux.intel.com> <20201022114946.GR20115@casper.infradead.org> <30ce6691-fd70-76a2-8b61-86d207c88713@nvidia.com> <20201026042158.GN20115@casper.infradead.org> <20201026132830.GQ20115@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201026132830.GQ20115@casper.infradead.org> 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, Oct 26, 2020 at 01:28:30PM +0000, Matthew Wilcox wrote: > > > It's been five years since DAX was merged, and page pinning still > > > doesn't work. How much longer before the people who are pushing it > > > realise that it's fundamentally flawed? > > > > Is this a separate rant about *only* DAX, or is general RDMA in your sights > > too? :) > > This is a case where it's not RDMA's _fault_ that there's no good API > for it to do what it needs to do. There's a lot of work needed to wean > Linux device drivers off their assumption that there's a struct page > for every byte of memory. People who care seem to have just given up and are using RDMA ODP, so I'm not optimistic this DAX issue will ever be solved. I've also almost removed all the struct page references from this flow in RDMA, so if there is some way that helps it is certainly doable. Regardless of DAX the pinning indication is now being used during fork() for some good reasons, and seems to make sense in other use cases. It just doesn't seem like a way to solve the DAX issue. More or less it seems to mean that pages pinned cannot be write protected and more broadly the kernel should not change the PTEs for those pages independently of the application. ie the more agressive COW on fork() caused data corruption regressions... I wonder if the point here is that some page owners can't/won't support DMA pinning and should just be blocked completely for them. I'd much rather have write access pin_user_pages() just fail than oops the kernel on ext4 owned VMAs, for instance. Jason