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 3BDF0C4363A for ; Mon, 26 Oct 2020 22:02:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9C87120829 for ; Mon, 26 Oct 2020 22:02:12 +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 9C87120829 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF53C6B005C; Mon, 26 Oct 2020 18:02:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A80096B005D; Mon, 26 Oct 2020 18:02:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 945CA6B0062; Mon, 26 Oct 2020 18:02:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id 5C0DD6B005C for ; Mon, 26 Oct 2020 18:02:11 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E81583622 for ; Mon, 26 Oct 2020 22:02:10 +0000 (UTC) X-FDA: 77415450420.03.limit21_1605d7c27276 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id C1FC628A4E8 for ; Mon, 26 Oct 2020 22:02:10 +0000 (UTC) X-HE-Tag: limit21_1605d7c27276 X-Filterd-Recvd-Size: 7730 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 26 Oct 2020 22:02:10 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id v5so13162777wmh.1 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=EMnuDYLsglNvP2uuYIezmnpc8l/D2K/235dO/Y0I1O8pzsh+/hFCxpzwrHMvGku/L8 sTJt1iD3YcyLKiucsXuDRFeHbkEyekksZwyuOQ4wo1iOA/AuEMZ1vX0cBiZ9KuicobeY Ne4X1T05DfNvrQ8YmWUOfYP1KpCfExi4Vy2zAYiwBpfwoxZlTFVHsTJxxpzboaSCWYvY BMNv+0uCqhC0MRt8nZkTC5HvqYQTNnTK2pEuYOMMZ6BUTkprTdgUG+1DILIcD/s08RSp sDI0rKS4JhD5KK7lG7Epje19pVtPOVIHLIpij5icU5WDJxnBFw3/6DjxDNBuHY/ff0OV /qGA== X-Gm-Message-State: AOAM533xhH3Ar6HYR/+2NBOzS3LF1MBe0PTRHf21WawnVIXZVoyMyBcc XQ6pXLwaDpvUO76azYNH6alxTQ== 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 In-Reply-To: <20201026105818.2585306-10-daniel.vetter@ffwll.ch> 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: 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=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(-) >=20 > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/me= dia/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 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 > 2.28.0 >=20