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,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 BF313C433DF for ; Sat, 10 Oct 2020 11:56:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2F6F22258 for ; Sat, 10 Oct 2020 11:56:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PmcQ6HnU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2F6F22258 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3594B6B0062; Sat, 10 Oct 2020 07:56:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E4276B0068; Sat, 10 Oct 2020 07:56:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 183466B006C; Sat, 10 Oct 2020 07:56:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id DBFC86B0062 for ; Sat, 10 Oct 2020 07:56:13 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 758271EF1 for ; Sat, 10 Oct 2020 11:56:13 +0000 (UTC) X-FDA: 77355862626.17.time30_2e096e7271e9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 5E078180D0180 for ; Sat, 10 Oct 2020 11:56:13 +0000 (UTC) X-HE-Tag: time30_2e096e7271e9 X-Filterd-Recvd-Size: 6733 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Sat, 10 Oct 2020 11:56:12 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id n2so13196618oij.1 for ; Sat, 10 Oct 2020 04:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kVkxIdHN6o3O+u6tSfedNSb1VzfwX2F8ZeWL/VdW1R0=; b=PmcQ6HnUaDFVR4ZG1jxYVR6Iy6yUiTRwMlYI1/tSbKPEa/kwoMlz7zfmOuI2hn6KYq V0dHtSf/LrEJbqhpaMjU8h/EJY/bF1jSwPEMaaWBwHAo1f9SuoP4vCo+L5gVrMpGB++A PnZ1b3eYUezb1GhvqoZ2KN7Thv1h+lAXB1upE= 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=kVkxIdHN6o3O+u6tSfedNSb1VzfwX2F8ZeWL/VdW1R0=; b=EVcOnjZ4EgFBUXMOxQSYXqnCyrBp5UYMHsLTmGh45psSi/QdnSH6qJ2nxH2aadoQoj qQGugK7uzty1dsxhvnpPTXFLaclzlQidaQI+Gd1d0zkbs6Aag1NfV4jTBjaOPKICAWhY gwVOxH7tgIXpOBH77ao47qheLfM/jyXCsN3ZDGqYbfQYIGvyFLJ/HQZAHC0HWzW15e8O zjgAOa9l7AlllDCldoZDysEPn6rd5iZfHAUyh20pRWG+Pi1n245vTKGLSQdHTN1WjwCC 6qpGQB8vRObWOXaxKoGnGIVaoniPFouuv9YYVOihQxGmOgpqrgbP/K8DfUjnXtc3NJPz RDyw== X-Gm-Message-State: AOAM530MJjb+9xyHHdiR445OeVzYSzZLWvT3Y1yNdpHj3wdFrHJyeFbw QcEU4dkpkFzV+o3LOVKJqKqfDxDK3O0EFS8k+PI/GQ== X-Google-Smtp-Source: ABdhPJzKftVU1haFUl3kJpPXCXE2YEa9neFI+uGYsToCivJpyHsTIlVZins4yYKilYPHMWVOsn/OllhI0jrgavqKgKA= X-Received: by 2002:aca:cc01:: with SMTP id c1mr3655546oig.128.1602330971569; Sat, 10 Oct 2020 04:56:11 -0700 (PDT) MIME-Version: 1.0 References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> <20201009122111.GN5177@ziepe.ca> <20201009143723.45609bfb@coco.lan> <20201009124850.GP5177@ziepe.ca> <20201010112122.587f9945@coco.lan> <20201010133929.746d0529@coco.lan> In-Reply-To: <20201010133929.746d0529@coco.lan> From: Daniel Vetter Date: Sat, 10 Oct 2020 13:56:00 +0200 Message-ID: Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn To: Mauro Carvalho Chehab Cc: Jason Gunthorpe , DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-s390 , Daniel Vetter , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Linus Torvalds 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 Sat, Oct 10, 2020 at 1:39 PM Mauro Carvalho Chehab wrote: > > Em Sat, 10 Oct 2020 12:53:49 +0200 > Daniel Vetter escreveu: > > > Hi Mauro, > > > > You might want to read the patches more carefully, because what you're > > demanding is what my patches do. Short summary: > > > > - if STRICT_FOLLOW_PFN is set: > > a) normal memory is handled as-is (i.e. your example works) through > > the addition of FOLL_LONGTERM. This is the "pin the pages correctly" > > approach you're demanding > > b) for non-page memory (zerocopy sharing before dma-buf was upstreamed > > is the only use-case for this) it is correctly rejected with -EINVAL > > > > - if you do have blobby userspace which requires the zero-copy using > > userptr to work, and doesn't have any of the fallbacks implemented > > that you describe, this would be a regression. That's why > > STRICT_FOLLOW_PFN can be unset. And yes there's a real security issue > > in this usage, Marek also confirmed that the removal of the vma copy > > code a few years ago essentially broke even the weak assumptions that > > made the code work 10+ years ago when it was merged. > > > > so tdlr; Everything you described will keep working even with the new > > flag set, and everything you demand must be implemented _is_ > > implemented in this patch series. > > > > Also please keep in mind that we are _not_ talking about the general > > userptr support that was merge ~20 years ago. This patch series here > > is _only_ about the zerocpy userptr support merged with 50ac952d2263 > > ("[media] videobuf2-dma-sg: Support io userptr operations on io > > memory") in 2013. > > Ok, now it is making more sense. Please update the comments for > patch 10/17 to describe the above. Will do. > We need some time to test this though, in order to check if no > regressions were added (except the ones due to changeset 50ac952d2263). Yeah testing of the previous patches to switch to FOLL_LONGTERM would be really good. I also need that for habanalabs and ideally exynos too. All the userptr for normal memory should keep working, and with FOLL_LONGTERM it should actually work better, since with that it should now correctly interact with pagecache and fs code, not just with anon memory from malloc. Thanks, Daniel > > Why this hack was merged in 2013 when we merged dma-buf almost 2 years > > before that I have no idea about. Imo that patch simply should never > > have landed, and instead dma-buf support prioritized. > > If I recall correctly, we didn't have any DMABUF support > at the media subsystem, back on 2013. > > It took some time for the DMA-BUF to arrive at media, as this > was not a top priority. Also, there aren't many developers that > understand the memory model well enough to implement DMA-BUF support > and touch the VB2 code, which is quite complex, as it supports > lots of different ways for I/O, plus works with vmalloc, DMA > contig and DMA scatter/gather. > > Changes there should carefully be tested against different > drivers, in order to avoid regressions on it. > > > Cheers, Daniel > > Thanks, > Mauro -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch