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 CC2DCC433DF for ; Sat, 10 Oct 2020 22:57:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 929252075E for ; Sat, 10 Oct 2020 22:57:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PmcQ6HnU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390562AbgJJW5w (ORCPT ); Sat, 10 Oct 2020 18:57:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730580AbgJJTvA (ORCPT ); Sat, 10 Oct 2020 15:51:00 -0400 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D85BC0613B9 for ; Sat, 10 Oct 2020 04:56:12 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id l85so13144966oih.10 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=kiwlf58p1ZqW0ZWT+jOzgKe1ESpqaSUV0D8w59XvyqiwuDp+f6vI7uitemiB/mwE+N pJP+XtslmM4oPJYoTmvyJGcqpxWim2GJPCVziCqUb3uRwAQ9PFfEo1cDWx4eILuhvz2j lPE9wm4Hg8vi66S4l2naY9amhddpOrxDYiPjp6x5yiqWRzkD5d8aPRAXlFPZ/Q+Tz69e 9lHKS8TUR9z5cIh+kMGeUz9XF1KHIT/Kiwri9LX4ijXCOzelu7mDu/uPJfQx+/IVh2+n ROmGeER5w8lOPcBmpMdFdi7mB7+a9rVL3wDarPKuZyvS4YzzPRdl82LeC3Wm2aq4GtDk 9grQ== X-Gm-Message-State: AOAM533vS0QNCXkjreg4TguHr4mUeqOf/2xJ7GwXb5iGUIbzE+NXiNPz EkQ+ZtjmhHhX7q8X15iyPJPV+dyVFQmUuCBh7ws0ew== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 92329C433DF for ; Sat, 10 Oct 2020 11:57:56 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 48F3C2072D for ; Sat, 10 Oct 2020 11:57:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AVw4RkL0"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PmcQ6HnU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48F3C2072D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5Cz5ADa9bQSUMySfUK/CNNeUIreUTx3pfFFTxlyFmy0=; b=AVw4RkL0ZPUoz39qAUj+V4NbU O1urFlgkglHA1bzbvIRVXugHW2CbnfrJKVSLU6hqZaiwRkimXTiMa0ScxHBs5+awRnuT3/UNjSNeF bUeWCDEx5rE15cCTQJ+5cSK2DUwE1kAw2/RdNWln4SHAYmlTaAZZCuLvBV59yL9ntzJ//BSOJQTEx w1t3XKwU4Te+rhz2VM73WAuvtEcKJGvbTabuGQuHF3tC5gayBWNftgBiUAjHOzRLdud/oVcTTtgRK e4Ky3K101q+6o/P0xhftD3unsyxE1MJGnLXplciZVq2GxmipY7L7fOyB5nLRUcqXUBpd2BcczXaub Zo7rbQUeA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRDU1-00023K-Bn; Sat, 10 Oct 2020 11:56:17 +0000 Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRDTx-00021D-Nj for linux-arm-kernel@lists.infradead.org; Sat, 10 Oct 2020 11:56:14 +0000 Received: by mail-oi1-x243.google.com with SMTP id z26so13124202oih.12 for ; Sat, 10 Oct 2020 04:56:13 -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=N2nhz/59s74Nbnpwe3fZT0QKFNCWC/Lrj3p/3DoKfKFNo9qkjizl0oLAmKRnv+IdS2 dpCVI4G8CXk0GqcODWYfXbZuV5DaTBcfreLl5RtS1/iHOtCYvAiXsB2fMX8ueY8CGI72 u8OEqf0XuoeaMpCWgUA8V3o+pW7eqNsJPAbySVtbspMPLeDIurnEDU6dUSB60kK5vFDi QjIKCUTdnwJi2LyMgkgs3snjSZpjTOQogg6W8nkHKxHj2QgM2piQt2cxWgFozbc9Qbv6 owCN/VbMJYShdCcoqcEdMEatvtfMkofR/9wTa3E2vwtbcSOQByCktXOdRYVoIRuOXchd TokA== X-Gm-Message-State: AOAM533SjsqLozMwFgU08IG9LvluTb0mNQAy6sUC3C+AGTOk3txbp9jF WL8n3pobhezF+jxCdEN4g7fRNGjFJw8gorZ645CeOg== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201010_075613_792493_9A389E6E X-CRM114-Status: GOOD ( 33.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390 , linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Jason Gunthorpe , John Hubbard , LKML , DRI Development , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Dan Williams , Linus Torvalds , Andrew Morton , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 65000C433E7 for ; Sat, 10 Oct 2020 11:56:15 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2BEDA2225A for ; Sat, 10 Oct 2020 11:56:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PmcQ6HnU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BEDA2225A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 583416EEB9; Sat, 10 Oct 2020 11:56:13 +0000 (UTC) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 54CCC6EEB9 for ; Sat, 10 Oct 2020 11:56:12 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id u17so13209495oie.3 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=QmHXexxayGgPQFA5zaNmb0DsNheqJbW6a/cfZnIdF8vgWJOhk4Z76CqgHvhBR6uuYT Kpdjz07MCdV0eJYFFR21lntJrVkjf2F5yqwpp48dwpZMMK5kGpWYBN85VGJ9f094k9rG 62ffOttGuwsNrMIIg35sGdYqo1axgoUW2gKA10T0l8NldddxOGldRkSetZfjOIjrmVWw I75gUdTltx1Itx9PhRd1+9vTW6ZIJjzjunrcw+hDvoA3XcEdxSNtHFOHpBPkGGSWXkpb mAaapfCTsIqe8/2436PQUzzK68y6/blQsIsq+tjaxi/9fSz6TpqLIIy4PIPBOj7Ub68a L0cg== X-Gm-Message-State: AOAM533wJ4uJupBSzsd/s2uad8hkYRTG4jJCyaltOtmbfIikRudVwWRx ABh+sMpp3TguKsEgLqYKVTFxXJ7hlp3SR9hjegCvnDvrrfjGSQ== 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 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390 , linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Jason Gunthorpe , John Hubbard , LKML , DRI Development , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Dan Williams , Linus Torvalds , Andrew Morton , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel