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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 7C05CC63777 for ; Fri, 20 Nov 2020 08:07:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 808842222F for ; Fri, 20 Nov 2020 08:07:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=xs4all.nl header.i=@xs4all.nl header.b="sCz/nqjJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 808842222F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9D39E6B0036; Fri, 20 Nov 2020 03:07:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 983616B005C; Fri, 20 Nov 2020 03:07:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 871E36B005D; Fri, 20 Nov 2020 03:07:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0099.hostedemail.com [216.40.44.99]) by kanga.kvack.org (Postfix) with ESMTP id 4D56F6B0036 for ; Fri, 20 Nov 2020 03:07:11 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D0D6F181AEF1E for ; Fri, 20 Nov 2020 08:07:10 +0000 (UTC) X-FDA: 77504066220.11.ocean00_441202c27349 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id B4355180F8B82 for ; Fri, 20 Nov 2020 08:07:10 +0000 (UTC) X-HE-Tag: ocean00_441202c27349 X-Filterd-Recvd-Size: 7076 Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 08:07:09 +0000 (UTC) Received: from cust-b5b5937f ([IPv6:fc0c:c16d:66b8:757f:c639:739b:9d66:799d]) by smtp-cloud7.xs4all.net with ESMTPA id g1RVk0X9Olmd2g1RYkPQEf; Fri, 20 Nov 2020 09:07:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s2; t=1605859628; bh=5ef7lI42EJC0jhODZv8aRbqRC0kxVqZ7bUU3H8kTkJ0=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type:From: Subject; b=sCz/nqjJKBqA3Iy+hXRhoPwJZL4RSnoEtFxis6hkV75LW75H+8Mmf4xAFrJVrm+pe 8hj9fY43X0dqeh5hcaBFUdzWOJyUGVN+kLdzF+HYD2GMKZ191HzrbBTSABtTsVzA60 CvFYS7ezfnr1FTaFjba06AEAIGK1cPKBvJnU0bV//E1AUEPH/j9aY3U67vZ93V4hF3 6I2h2Od2vKJaEqVVhdF9KG8FIUuOZ8CG53hsXtNKL1Ch1fABIwEX5ve+bjxpFXGSyB aulCIunjrg9nl2+Y0ytv3CWHuxLF8HC5EnBBERF6rxbWpTScSnwiEMYNWkAwQXYMxf cBr7jUjdLWeiw== Subject: Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe To: Daniel Vetter , DRI Development , LKML Cc: 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, Tomasz Figa , Daniel Vetter , Jason Gunthorpe , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Laurent Dufour , Vlastimil Babka , Daniel Jordan , Michel Lespinasse References: <20201119144146.1045202-1-daniel.vetter@ffwll.ch> <20201119144146.1045202-10-daniel.vetter@ffwll.ch> From: Hans Verkuil Message-ID: Date: Fri, 20 Nov 2020 09:06:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201119144146.1045202-10-daniel.vetter@ffwll.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-CMAE-Envelope: MS4xfFkC2JJwDijdDHxk6QLdzYl86sxkzUvUR2rXQtLzS7Z3VCur8Sec0yc9/yj+teseucfM5Id3FSotdLzmsmr0WrYFYFXWblZvd586PxVzp7yalD+lMMTn /GP83mNKzjc5heCNLfvA46owaFZXBn0xPi+CrgcCTXCH+zCXDT/AugYk6WH31S/1fbilR/Bbn3VeP/VhTIjFK4ZkC7eOo9LJEqJWAP4kRBAdILmunjJmxXCT T9pw+MuwA6aQValWt8fR+2+Lohjgd26Kp3nsob/wGjkR2luEcNWBtmlzFVNrH+o+PP5aQAr4PDD+Z3dwOYMFNf76JTi6TFmlFZu78KxaX22EGz/bSPQghfFt yr7PTAmX010Y9mMvI/xJ8+OsZxM4+7H5b5EdPvoogEg/pCMQmvIqXLrivqredG5EOF57yPgwvUWyST9kqoBQZ0Y5vkkhX1LEjhptReds6BhrXH1RbB7N/mgZ ZNy1MjlvK64zXtOJ8uXaMBuHmzQtKNk3YzD5aJoakoowrkbNlF3olnS6jqrDz84rGP635GzH4xQ2JVz/bYDGw6/RyYu6BwKwqJsYho1oIn5pWJtwG6eL4Sys WJAb+ARL9Ka4wQ5SjbYr73z0jlMszhtNG0g91E+gV/ngoX+TfzOw3D4uv9zhis07qCCrZd9mZ+HYWRB2t95Ix5qwHZnN7P6GbcP06CUCv3W3u8KpUPI+dEI0 b7vGOZDkWvFsE1dmLjD9sCa6x/ZGIgVOw626FWzt8bTHFsqPP2Z98RzxcN50nCJkPPI4P7rtQrMlsZmhmzigHBYPfh6cR7KNLyviHXr0Ek3rvsLoxjZOhR9P ZAaqSLxwNMHu8kbI+D4pvREzqEx2gbSD1KX/g26bCR0cSsz8hqf0mItBK2Ua6ADVuO/ZaLWD+DrKIUrbYZn3vfZdKI8Mrv3xJUieHzHB/b6gDHFWvMdfKJii mpsBubC9N+hw7++PiHs0zH7FLmEY2rO4oZf0kE/dqwF7EyrF Content-Transfer-Encoding: quoted-printable 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 19/11/2020 15:41, 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"). >=20 > Acked-by: Tomasz Figa Acked-by: Hans Verkuil Thanks! Hans > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: J=C3=A9r=C3=B4me 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/me= dia/common/videobuf2/frame_vector.c > index a0e65481a201..1a82ec13ea00 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned in= t 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/me= dia/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 vide= obuf_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