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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 67F69C4363A for ; Sun, 11 Oct 2020 06:27:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0E1FC207FB for ; Sun, 11 Oct 2020 06:27:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gtB49X5+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E1FC207FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6BF0A6B0071; Sun, 11 Oct 2020 02:27:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6473F6B0072; Sun, 11 Oct 2020 02:27:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E7C46B0073; Sun, 11 Oct 2020 02:27:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 192E86B0071 for ; Sun, 11 Oct 2020 02:27:51 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 98413181AE868 for ; Sun, 11 Oct 2020 06:27:50 +0000 (UTC) X-FDA: 77358663900.24.fuel22_2d0358a271ef Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 7A8A41A4A0 for ; Sun, 11 Oct 2020 06:27:50 +0000 (UTC) X-HE-Tag: fuel22_2d0358a271ef X-Filterd-Recvd-Size: 5717 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Sun, 11 Oct 2020 06:27:49 +0000 (UTC) Received: from coco.lan (ip5f5ad5a3.dynamic.kabel-deutschland.de [95.90.213.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 70D4020795; Sun, 11 Oct 2020 06:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602397669; bh=tLwirr0BbVJkwRy4pXH9jkVKcUQIWYnty1vsXbo4I7E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gtB49X5+yRzhY33+NnJemfNod8lA4EL1Bqf7vnxS+zQy5xIyntEJPhyD+Zkw5nmnp hOC6+lfj7NYWVVXkGO3liFxjebMkF5+P4r0kPw+axWc2cWV3GRAHNiyZ1mAgRt4Vya asb/PYhs/guNq8+Ak1psm0EqVQbOy4RYr8En3mf8= Date: Sun, 11 Oct 2020 08:27:41 +0200 From: Mauro Carvalho Chehab To: Daniel Vetter Cc: Laurent Pinchart , Tomasz Figa , linux-s390 , linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Linux MM , John Hubbard , LKML , DRI Development , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWU=?= Glisse , Daniel Vetter , Dan Williams , Linus Torvalds , Andrew Morton , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" , Hans Verkuil , "Lad, Prabhakar" Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn Message-ID: <20201011082741.6bed4d71@coco.lan> In-Reply-To: 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> <20201010213554.GD3939@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Em Sat, 10 Oct 2020 23:50:27 +0200 Daniel Vetter escreveu: > On Sat, Oct 10, 2020 at 11:36 PM Laurent Pinchart > wrote: > > > > > We probably still have a few legacy drivers using videobuf (non-2), > > > but IMHO those should be safe to put behind some disabled-by-default > > > Kconfig symbol or even completely drop, as the legacy framework has > > > been deprecated for many years already. > > > > There's 8 drivers left, and they support a very large number of devices. > > I expect unhappy users distros stop shipping them. On the other hand, > > videobuf has been deprecated for a loooooooong time, so there has been > > plenty of time to convert the remaining drivers to videobuf2. If nobody > > can do it, then we'll have to drop support for these devices given the > > security issues. > > Again, the issue here is _only_ with follow_pfn. For videobuf1 this > means videbuf-dma-contig.c userptr support is broken. Unlike videobuf2 > it means it's broken for all usage (not just zero-copy userptr), > because videbuf-dma-contig.c lacks the pin_user_pages path. Well, follow_pfn() is used only by videbuf-dma-contig.c. If this is the only part of VB1 that will have userptr broken, then there's just one driver that might be affected: davinci. Yet, taking a deeper look: $ git grep include drivers/media/platform/davinci/|grep -i videobuf drivers/media/platform/davinci/vpif_capture.h:#include drivers/media/platform/davinci/vpif_display.h:#include It sounds to me that it was already converted to VB2, but some VB1 symbols were not converted at its Kconfig. It sounds to me that there are other drivers with some VB1 left overs at Kconfig, as those are the only ones using VB1 those days: $ for i in $(git grep media/videobuf drivers |grep -v videobuf2 |grep -v v4l2-core|cut -d: -f1); do dirname $i; done|sort|uniq drivers/media/pci/bt8xx drivers/media/pci/cx18 drivers/media/platform drivers/media/usb/tm6000 drivers/media/usb/zr364xx drivers/staging/media/atomisp/pci > But that > would be easy to add if this poses a problem I think - we just need > to carry over the pin_user_pages_fast logic from videbuf2, no driver > changes required. But of course I don't think we should do that before > someone reports the regression, since videobuf1 userptr is doubly > deprecated :-) I think otherwise. Keeping a broken component at the Kernel is a bad idea. Yet, from my quick search above, it sounds to me that it is time for us to retire the VB1 DMA contig support as a hole, as there's no client for it anymore. I'll work on some patches cleaning up the VB1 left overs at Kconfig and removing videbuf-dma-contig.c for good, if there's no hidden dependency on it. Thanks, Mauro