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=-9.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 1FDCAC5517A for ; Mon, 26 Oct 2020 22:02:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D4DB1207F7 for ; Mon, 26 Oct 2020 22:02:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="aNdxfyvH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391660AbgJZWCO (ORCPT ); Mon, 26 Oct 2020 18:02:14 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:50858 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391640AbgJZWCN (ORCPT ); Mon, 26 Oct 2020 18:02:13 -0400 Received: by mail-wm1-f67.google.com with SMTP id 13so13158802wmf.0 for ; Mon, 26 Oct 2020 15:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=nnyXk2pMcKjBK4+Fq7Fk4IbVXn2gczxbne31w99Uqrk=; b=aNdxfyvHxW5EhJys38x8msSr36mwdr8ntNEXWK/+T2/MzKfU0VCnCWyghyZeK0cVeb rA0iLh+uHuE4kyJ2TJC3GpOOr5wl+e2jm2smdq02RkePbEEuN++cEauu/TxifEzN74sA tq59FL7KLoIUR9iPLa6VmUTM39rV8IcMJlYBc= 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:content-transfer-encoding :in-reply-to; bh=nnyXk2pMcKjBK4+Fq7Fk4IbVXn2gczxbne31w99Uqrk=; b=B4/Cgz1Y1mRY0dj3dg2MxbxUuK4RDbFqAcXHzrwlwDPnFrhJlIsMKY4Zlf2zGIquh3 iVH6pn2JbeJmSc0Se8+6aXurifxkaS1eZjmsxl1ZDTn8mIX+SaQuh/UprkpsFVYHmXVU vKIxUw9KgWhvCtgWEMzupzn3SMi87AOlFuvLy5ZALlXEcmw0YUERDJheOxWqn5BzE2Zs NXrUwacz8/4gihSWHLjh9z/iCs7u5Jmdqv8uL1hQisucCwDWHaelleg2NjBRsEJKuAuQ gK2fq76xDTu9rVpT/KEMoHNF4KbWWl3pDUrZtETG1mZn3OLroiM0RZjhHKpLIiNuWOKm mGNw== X-Gm-Message-State: AOAM532UDLLkcnSRwdH+BeS/CG07QKORtI/OfzT5YMgdqQZYuZZzNn49 sUe23XLZnheOpcLYwSeagKpxDQ== X-Google-Smtp-Source: ABdhPJwXQQfk3H55i6k/BF7MPc09Wr29zTiROpPA8yChYSvzhbxp82tIcqHTWfVny/00bz/9GBIJdQ== X-Received: by 2002:a1c:bc06:: with SMTP id m6mr19364153wmf.68.1603749728982; Mon, 26 Oct 2020 15:02:08 -0700 (PDT) Received: from chromium.org (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id t7sm23634700wrx.42.2020.10.26.15.02.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 15:02:08 -0700 (PDT) Date: Mon, 26 Oct 2020 22:02:06 +0000 From: Tomasz Figa To: Daniel Vetter Cc: DRI Development , LKML , kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-s390@vger.kernel.org, Daniel Vetter , Jason Gunthorpe , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?iso-8859-1?B?Suly9G1l?= Glisse , Jan Kara , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Laurent Dufour , Vlastimil Babka , Daniel Jordan , Michel Lespinasse Subject: Re: [PATCH v4 09/15] media/videbuf1|2: Mark follow_pfn usage as unsafe Message-ID: <20201026220206.GA2802004@chromium.org> References: <20201026105818.2585306-1-daniel.vetter@ffwll.ch> <20201026105818.2585306-10-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201026105818.2585306-10-daniel.vetter@ffwll.ch> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On Mon, Oct 26, 2020 at 11:58:12AM +0100, Daniel Vetter wrote: > The media model assumes that buffers are all preallocated, so that > when a media pipeline is running we never miss a deadline because the > buffers aren't allocated or available. > > This means we cannot fix the v4l follow_pfn usage through > mmu_notifier, without breaking how this all works. The only real fix > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and > tell everyone to cut over to dma-buf memory sharing for zerocopy. > > userptr for normal memory will keep working as-is, this only affects > the zerocopy userptr usage enabled in 50ac952d2263 ("[media] > videobuf2-dma-sg: Support io userptr operations on io memory"). Note that this is true only for the videobuf2 change. The videobuf1 code was like this all the time and does not support normal memory in the dma_contig variant (because normal memory is rarely physically contiguous). If my understanding is correct that the CONFIG_STRICT_FOLLOW_PFN is not enabled by default, we stay backwards compatible, with only whoever decides to turn it on risking a breakage. I agree that this is a good first step towards deprecating this legacy code, so: Acked-by: Tomasz Figa Of course the last word goes to Mauro. :) Best regards, Tomasz > > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: Jérôme Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Pawel Osciak > Cc: Marek Szyprowski > Cc: Kyungmin Park > Cc: Tomasz Figa > Cc: Laurent Dufour > Cc: Vlastimil Babka > Cc: Daniel Jordan > Cc: Michel Lespinasse > Signed-off-by: Daniel Vetter > -- > v3: > - Reference the commit that enabled the zerocopy userptr use case to > make it abundandtly clear that this patch only affects that, and not > normal memory userptr. The old commit message already explained that > normal memory userptr is unaffected, but I guess that was not clear > enough. > --- > drivers/media/common/videobuf2/frame_vector.c | 2 +- > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c > index 6590987c14bd..e630494da65c 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > break; > > while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) { > - err = follow_pfn(vma, start, &nums[ret]); > + err = unsafe_follow_pfn(vma, start, &nums[ret]); > if (err) { > if (ret == 0) > ret = err; > diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c > index 52312ce2ba05..821c4a76ab96 100644 > --- a/drivers/media/v4l2-core/videobuf-dma-contig.c > +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c > @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem, > user_address = untagged_baddr; > > while (pages_done < (mem->size >> PAGE_SHIFT)) { > - ret = follow_pfn(vma, user_address, &this_pfn); > + ret = unsafe_follow_pfn(vma, user_address, &this_pfn); > if (ret) > break; > > -- > 2.28.0 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f65.google.com ([209.85.128.65]:52362 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391636AbgJZWCL (ORCPT ); Mon, 26 Oct 2020 18:02:11 -0400 Received: by mail-wm1-f65.google.com with SMTP id c194so13164070wme.2 for ; Mon, 26 Oct 2020 15:02:09 -0700 (PDT) Date: Mon, 26 Oct 2020 22:02:06 +0000 From: Tomasz Figa Subject: Re: [PATCH v4 09/15] media/videbuf1|2: Mark follow_pfn usage as unsafe Message-ID: <20201026220206.GA2802004@chromium.org> References: <20201026105818.2585306-1-daniel.vetter@ffwll.ch> <20201026105818.2585306-10-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20201026105818.2585306-10-daniel.vetter@ffwll.ch> List-ID: To: Daniel Vetter Cc: DRI Development , LKML , kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-s390@vger.kernel.org, Daniel Vetter , Jason Gunthorpe , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?iso-8859-1?B?Suly9G1l?= Glisse , Jan Kara , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Laurent Dufour , Vlastimil Babka , Daniel Jordan , Michel Lespinasse Hi Daniel, On Mon, Oct 26, 2020 at 11:58:12AM +0100, Daniel Vetter wrote: > The media model assumes that buffers are all preallocated, so that > when a media pipeline is running we never miss a deadline because the > buffers aren't allocated or available. >=20 > This means we cannot fix the v4l follow_pfn usage through > mmu_notifier, without breaking how this all works. The only real fix > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and > tell everyone to cut over to dma-buf memory sharing for zerocopy. >=20 > userptr for normal memory will keep working as-is, this only affects > the zerocopy userptr usage enabled in 50ac952d2263 ("[media] > videobuf2-dma-sg: Support io userptr operations on io memory"). Note that this is true only for the videobuf2 change. The videobuf1 code was like this all the time and does not support normal memory in the dma_contig variant (because normal memory is rarely physically contiguous). If my understanding is correct that the CONFIG_STRICT_FOLLOW_PFN is not enabled by default, we stay backwards compatible, with only whoever decides to turn it on risking a breakage. I agree that this is a good first step towards deprecating this legacy code, so: Acked-by: Tomasz Figa Of course the last word goes to Mauro. :) Best regards, Tomasz >=20 > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: J=EF=BF=BDr=EF=BF=BDme Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Pawel Osciak > Cc: Marek Szyprowski > Cc: Kyungmin Park > Cc: Tomasz Figa > Cc: Laurent Dufour > Cc: Vlastimil Babka > Cc: Daniel Jordan > Cc: Michel Lespinasse > Signed-off-by: Daniel Vetter > -- > v3: > - Reference the commit that enabled the zerocopy userptr use case to > make it abundandtly clear that this patch only affects that, and not > normal memory userptr. The old commit message already explained that > normal memory userptr is unaffected, but I guess that was not clear > enough. > --- > drivers/media/common/videobuf2/frame_vector.c | 2 +- > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/medi= a/common/videobuf2/frame_vector.c > index 6590987c14bd..e630494da65c 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int = nr_frames, > break; > =20 > while (ret < nr_frames && start + PAGE_SIZE <=3D vma->vm_end) { > - err =3D follow_pfn(vma, start, &nums[ret]); > + err =3D unsafe_follow_pfn(vma, start, &nums[ret]); > if (err) { > if (ret =3D=3D 0) > ret =3D err; > diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/medi= a/v4l2-core/videobuf-dma-contig.c > index 52312ce2ba05..821c4a76ab96 100644 > --- a/drivers/media/v4l2-core/videobuf-dma-contig.c > +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c > @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct videob= uf_dma_contig_memory *mem, > user_address =3D untagged_baddr; > =20 > while (pages_done < (mem->size >> PAGE_SHIFT)) { > - ret =3D follow_pfn(vma, user_address, &this_pfn); > + ret =3D unsafe_follow_pfn(vma, user_address, &this_pfn); > if (ret) > break; > =20 > --=20 > 2.28.0 >=20 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=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 2E7C0C5517A for ; Mon, 26 Oct 2020 22:03:58 +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 C4FB42084C for ; Mon, 26 Oct 2020 22:03:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FSIRM/eo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="aNdxfyvH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4FB42084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dnR1394W7lekB1Tp7ffeo/d2cNqY6XmVbXuQlN+dzGc=; b=FSIRM/eoz3n4ZYeehlvefwykn yqLmfZ4hb/K+IGSP6Uz0oIn7H5wmvR4Kwcz2ZcHfQdWTnZR6baQ+epaVP6r8sH5mI/pW3xAyxi7nj Nwg4/gs4EPbToPrJ3a6D0M+9C7lL0vxOccKxbD4wMZtFDfoA3SfwN8GQ1eD7j9wsgd8KOo7fSE7pg E7KIRtopK0N4Lkj9FejvE0HVs8PMOh3Kypt98f7wGKVYxIjvzQSqu2lWQgB9Z7QuoJCO2uH8sKRzr TuhR2SR0C+9nrjyGh8hRi4PQO9zkUi5IpilLticXaPQwRfMjiSfB4YE2stqFRwaeSFRZWyIpkiXxY C5EAHpfWQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXAZD-0006bB-OI; Mon, 26 Oct 2020 22:02:15 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXAZA-0006Zh-99 for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 22:02:13 +0000 Received: by mail-wm1-x344.google.com with SMTP id e2so14031939wme.1 for ; Mon, 26 Oct 2020 15:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=nnyXk2pMcKjBK4+Fq7Fk4IbVXn2gczxbne31w99Uqrk=; b=aNdxfyvHxW5EhJys38x8msSr36mwdr8ntNEXWK/+T2/MzKfU0VCnCWyghyZeK0cVeb rA0iLh+uHuE4kyJ2TJC3GpOOr5wl+e2jm2smdq02RkePbEEuN++cEauu/TxifEzN74sA tq59FL7KLoIUR9iPLa6VmUTM39rV8IcMJlYBc= 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:content-transfer-encoding :in-reply-to; bh=nnyXk2pMcKjBK4+Fq7Fk4IbVXn2gczxbne31w99Uqrk=; b=P0gd0Ck6Wj4Gn4fpxEWgKdKhuLRnMuyGx6k52+rfhSczbQMR6zymoCUDSnUZwkAQyq 9EMc0XJQ/YCNdkdE9rCwvwa0LXR2fnrj5hMzFr2IdHlEPx5lB/RAXziIHNtunNl5ifRv Wr1kMj7ZP9gajW1Z/L1L8i6neH/gFnQYXQ1ltZ2meuGyhYK/3+4VyfIdOfwT/9H1yCDg EeXMYqArt2RqjHY4CCzCCM9QB4b1do3AVXSn+dbcGXl3HwtEn/vD92aSNYEtRMUVKFg7 hB+uWeeKdm8YgHMP0sh/53bYNAHCy4pfp8OGWyOeqR/BK0NaHfsEFPRnA3irEvu/ysJ1 Cvpw== X-Gm-Message-State: AOAM531hwMrqcbC7DH5ksPtwhE5UhCfX8/B/Fm648eFw54qGI8NHNwdL Zeg6iwYVt+YcdDuyoWamnR43fEjmzBi3bQ== X-Google-Smtp-Source: ABdhPJwXQQfk3H55i6k/BF7MPc09Wr29zTiROpPA8yChYSvzhbxp82tIcqHTWfVny/00bz/9GBIJdQ== X-Received: by 2002:a1c:bc06:: with SMTP id m6mr19364153wmf.68.1603749728982; Mon, 26 Oct 2020 15:02:08 -0700 (PDT) Received: from chromium.org (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id t7sm23634700wrx.42.2020.10.26.15.02.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 15:02:08 -0700 (PDT) Date: Mon, 26 Oct 2020 22:02:06 +0000 From: Tomasz Figa To: Daniel Vetter Subject: Re: [PATCH v4 09/15] media/videbuf1|2: Mark follow_pfn usage as unsafe Message-ID: <20201026220206.GA2802004@chromium.org> References: <20201026105818.2585306-1-daniel.vetter@ffwll.ch> <20201026105818.2585306-10-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201026105818.2585306-10-daniel.vetter@ffwll.ch> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201026_180212_442375_3A2F6E2E X-CRM114-Status: GOOD ( 29.50 ) 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: Jan Kara , kvm@vger.kernel.org, DRI Development , linux-mm@kvack.org, Daniel Vetter , Michel Lespinasse , Marek Szyprowski , linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, Daniel Jordan , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, Kees Cook , Pawel Osciak , John Hubbard , =?iso-8859-1?B?Suly9G1l?= Glisse , Dan Williams , Laurent Dufour , Vlastimil Babka , LKML , Kyungmin Park , Andrew Morton Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Daniel, On Mon, Oct 26, 2020 at 11:58:12AM +0100, Daniel Vetter wrote: > The media model assumes that buffers are all preallocated, so that > when a media pipeline is running we never miss a deadline because the > buffers aren't allocated or available. > = > This means we cannot fix the v4l follow_pfn usage through > mmu_notifier, without breaking how this all works. The only real fix > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and > tell everyone to cut over to dma-buf memory sharing for zerocopy. > = > userptr for normal memory will keep working as-is, this only affects > the zerocopy userptr usage enabled in 50ac952d2263 ("[media] > videobuf2-dma-sg: Support io userptr operations on io memory"). Note that this is true only for the videobuf2 change. The videobuf1 code was like this all the time and does not support normal memory in the dma_contig variant (because normal memory is rarely physically contiguous). If my understanding is correct that the CONFIG_STRICT_FOLLOW_PFN is not enabled by default, we stay backwards compatible, with only whoever decides to turn it on risking a breakage. I agree that this is a good first step towards deprecating this legacy code, so: Acked-by: Tomasz Figa Of course the last word goes to Mauro. :) Best regards, Tomasz > = > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: J=E9r=F4me Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Pawel Osciak > Cc: Marek Szyprowski > Cc: Kyungmin Park > Cc: Tomasz Figa > Cc: Laurent Dufour > Cc: Vlastimil Babka > Cc: Daniel Jordan > Cc: Michel Lespinasse > Signed-off-by: Daniel Vetter > -- > v3: > - Reference the commit that enabled the zerocopy userptr use case to > make it abundandtly clear that this patch only affects that, and not > normal memory userptr. The old commit message already explained that > normal memory userptr is unaffected, but I guess that was not clear > enough. > --- > drivers/media/common/videobuf2/frame_vector.c | 2 +- > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > = > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/medi= a/common/videobuf2/frame_vector.c > index 6590987c14bd..e630494da65c 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int = nr_frames, > break; > = > while (ret < nr_frames && start + PAGE_SIZE <=3D vma->vm_end) { > - err =3D follow_pfn(vma, start, &nums[ret]); > + err =3D unsafe_follow_pfn(vma, start, &nums[ret]); > if (err) { > if (ret =3D=3D 0) > ret =3D err; > diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/medi= a/v4l2-core/videobuf-dma-contig.c > index 52312ce2ba05..821c4a76ab96 100644 > --- a/drivers/media/v4l2-core/videobuf-dma-contig.c > +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c > @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct videob= uf_dma_contig_memory *mem, > user_address =3D untagged_baddr; > = > while (pages_done < (mem->size >> PAGE_SHIFT)) { > - ret =3D follow_pfn(vma, user_address, &this_pfn); > + ret =3D unsafe_follow_pfn(vma, user_address, &this_pfn); > if (ret) > break; > = > -- = > 2.28.0 > = _______________________________________________ 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=-9.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 A25DEC2D0A3 for ; Mon, 26 Oct 2020 22:02:13 +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 4E24D207F7 for ; Mon, 26 Oct 2020 22:02:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="aNdxfyvH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E24D207F7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 3ECCD6EA79; Mon, 26 Oct 2020 22:02:12 +0000 (UTC) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by gabe.freedesktop.org (Postfix) with ESMTPS id 40BEB6EA79 for ; Mon, 26 Oct 2020 22:02:10 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id a72so13167484wme.5 for ; Mon, 26 Oct 2020 15:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=nnyXk2pMcKjBK4+Fq7Fk4IbVXn2gczxbne31w99Uqrk=; b=aNdxfyvHxW5EhJys38x8msSr36mwdr8ntNEXWK/+T2/MzKfU0VCnCWyghyZeK0cVeb rA0iLh+uHuE4kyJ2TJC3GpOOr5wl+e2jm2smdq02RkePbEEuN++cEauu/TxifEzN74sA tq59FL7KLoIUR9iPLa6VmUTM39rV8IcMJlYBc= 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:content-transfer-encoding :in-reply-to; bh=nnyXk2pMcKjBK4+Fq7Fk4IbVXn2gczxbne31w99Uqrk=; b=Q7xPc2buFJUjnlvRVjoeX3UcDGCPU/78eKGbCVJf9iQKLc7GcySqymArsLbqKxoOOS 62fJKnEcj7NQiwTRpjNvXybscK9LtPY3wXf30qf+x0OWJX5cHzq6Z0GcDPWueGEZGzt+ IU852ztnp6NB6C8CFoRJDl6d3h3VNr2Cwpfh3Pod1hr+37P6DT7tvMQqYxwgGZB2yBbT hVU4fz0kp8xqNhlufZj/MTmml0iGILqdE1fuUofPX0zEczK7zu0+5kVHwvq+s3V67DZl Npjpoo86ZCpaI7wCkd+EQjNIf6E1TchwMu2BFDDTcUwHfEqXfrqF5fjBAlH+KmR1kVVv TwYQ== X-Gm-Message-State: AOAM5320RB/Q5RJQ6DoUfAYxprWr23W+voUNr/YBxt1Dx0j3OSBPUHES rI0GM1mcXFebcEQtqjt2r34LNg== X-Google-Smtp-Source: ABdhPJwXQQfk3H55i6k/BF7MPc09Wr29zTiROpPA8yChYSvzhbxp82tIcqHTWfVny/00bz/9GBIJdQ== X-Received: by 2002:a1c:bc06:: with SMTP id m6mr19364153wmf.68.1603749728982; Mon, 26 Oct 2020 15:02:08 -0700 (PDT) Received: from chromium.org (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id t7sm23634700wrx.42.2020.10.26.15.02.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 15:02:08 -0700 (PDT) Date: Mon, 26 Oct 2020 22:02:06 +0000 From: Tomasz Figa To: Daniel Vetter Subject: Re: [PATCH v4 09/15] media/videbuf1|2: Mark follow_pfn usage as unsafe Message-ID: <20201026220206.GA2802004@chromium.org> References: <20201026105818.2585306-1-daniel.vetter@ffwll.ch> <20201026105818.2585306-10-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201026105818.2585306-10-daniel.vetter@ffwll.ch> 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: Jan Kara , kvm@vger.kernel.org, DRI Development , linux-mm@kvack.org, Daniel Vetter , Michel Lespinasse , Marek Szyprowski , linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, Daniel Jordan , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, Kees Cook , Pawel Osciak , John Hubbard , =?iso-8859-1?B?Suly9G1l?= Glisse , Dan Williams , Laurent Dufour , Vlastimil Babka , LKML , Kyungmin Park , Andrew Morton Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Daniel, On Mon, Oct 26, 2020 at 11:58:12AM +0100, Daniel Vetter wrote: > The media model assumes that buffers are all preallocated, so that > when a media pipeline is running we never miss a deadline because the > buffers aren't allocated or available. > = > This means we cannot fix the v4l follow_pfn usage through > mmu_notifier, without breaking how this all works. The only real fix > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and > tell everyone to cut over to dma-buf memory sharing for zerocopy. > = > userptr for normal memory will keep working as-is, this only affects > the zerocopy userptr usage enabled in 50ac952d2263 ("[media] > videobuf2-dma-sg: Support io userptr operations on io memory"). Note that this is true only for the videobuf2 change. The videobuf1 code was like this all the time and does not support normal memory in the dma_contig variant (because normal memory is rarely physically contiguous). If my understanding is correct that the CONFIG_STRICT_FOLLOW_PFN is not enabled by default, we stay backwards compatible, with only whoever decides to turn it on risking a breakage. I agree that this is a good first step towards deprecating this legacy code, so: Acked-by: Tomasz Figa Of course the last word goes to Mauro. :) Best regards, Tomasz > = > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: J=E9r=F4me Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Pawel Osciak > Cc: Marek Szyprowski > Cc: Kyungmin Park > Cc: Tomasz Figa > Cc: Laurent Dufour > Cc: Vlastimil Babka > Cc: Daniel Jordan > Cc: Michel Lespinasse > Signed-off-by: Daniel Vetter > -- > v3: > - Reference the commit that enabled the zerocopy userptr use case to > make it abundandtly clear that this patch only affects that, and not > normal memory userptr. The old commit message already explained that > normal memory userptr is unaffected, but I guess that was not clear > enough. > --- > drivers/media/common/videobuf2/frame_vector.c | 2 +- > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > = > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/medi= a/common/videobuf2/frame_vector.c > index 6590987c14bd..e630494da65c 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int = nr_frames, > break; > = > while (ret < nr_frames && start + PAGE_SIZE <=3D vma->vm_end) { > - err =3D follow_pfn(vma, start, &nums[ret]); > + err =3D unsafe_follow_pfn(vma, start, &nums[ret]); > if (err) { > if (ret =3D=3D 0) > ret =3D err; > diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/medi= a/v4l2-core/videobuf-dma-contig.c > index 52312ce2ba05..821c4a76ab96 100644 > --- a/drivers/media/v4l2-core/videobuf-dma-contig.c > +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c > @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct videob= uf_dma_contig_memory *mem, > user_address =3D untagged_baddr; > = > while (pages_done < (mem->size >> PAGE_SHIFT)) { > - ret =3D follow_pfn(vma, user_address, &this_pfn); > + ret =3D unsafe_follow_pfn(vma, user_address, &this_pfn); > if (ret) > break; > = > -- = > 2.28.0 > = _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel