Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14430775rwb; Mon, 28 Nov 2022 00:23:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf6AHm62V4LnTyPEfJusr6Wu7OAMBkdYhS+2ENeTpuhchqmqtchjwow4u2ITDf3mRwQ5jo5O X-Received: by 2002:a05:6402:1013:b0:463:f3a:32ce with SMTP id c19-20020a056402101300b004630f3a32cemr30408465edu.366.1669623823445; Mon, 28 Nov 2022 00:23:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669623823; cv=none; d=google.com; s=arc-20160816; b=Os/gHsGzAsXlIK6h2m9KjO4ejnSnhUeyZQTV0WqmiofOfF4j+jCH1poVhIJjXs2pct x91LJxpZfSU+tyCLEKFMORtq1l8lf+gHIn6BSBRnRvpasXCPNYPeJ0DIOGYvC96wrL3I iJkj9diDjoHT7kvkrmYYcVywldwxj0prNbs0phX+/dI+q3QrpScc34fSC4daiqSJQjnX SA99IjM7SK0rUlNEQIX21Zk6tqkG22ZXYqVUj9VLC4OuVbin2MQkX6N73AS+N/mPPC3o HlM0wMtpaGVacSVOxItacYrs3Vya49A1yExcEtmBgfBDIisa9uSoDSyX4mNkVWHzE8If LBkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id; bh=4M+eHSD3lZsFOpCRPlbO4LN4zRm33IaQkX0vPy7gm18=; b=e1P7N8CeTVo1qet9dsVivvk4SB1Hkbl3BLg1HIWXvUdMSQp/VqsdYi9T0SuKdeyuPL XY864d6B7rhabH6XKmDHQTjqp460EWODry8L8hYOuVI3cQB6g4O3Mdk9EJncKhjA5fyH xVz+xkM533kkZjUnWI3xdMi+WrqczqvD77C388dp3fwqlzSKx2jYMGBnfO174BGpzHwT g3/0jzb4lHNNsTrBV8mmSguSVmeVOtZY2b4+UfJjs+JWmztgnwqY2H/xgBIJR21R7PFy g3fNtRXRyKluunn2g/V/q5UMzUlISYD4DqdxbrnBj0uYnkfSyUsQ9Sn85V1y/AWrHjx1 YUUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l24-20020a056402231800b004615937b174si8156395eda.480.2022.11.28.00.23.23; Mon, 28 Nov 2022 00:23:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230088AbiK1IRP (ORCPT + 84 others); Mon, 28 Nov 2022 03:17:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbiK1IRN (ORCPT ); Mon, 28 Nov 2022 03:17:13 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3F5D5FC2; Mon, 28 Nov 2022 00:17:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7B7ABB80B3A; Mon, 28 Nov 2022 08:17:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF774C433D6; Mon, 28 Nov 2022 08:17:01 +0000 (UTC) Message-ID: <08b65ac6-6786-1080-18f8-d2be109c85fc@xs4all.nl> Date: Mon, 28 Nov 2022 09:17:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: en-US To: David Hildenbrand , linux-kernel@vger.kernel.org, Andrew Morton Cc: x86@kernel.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-perf-users@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, Linus Torvalds , Jason Gunthorpe , John Hubbard , Peter Xu , Greg Kroah-Hartman , Andrea Arcangeli , Hugh Dickins , Nadav Amit , Vlastimil Babka , Matthew Wilcox , Mike Kravetz , Muchun Song , Shuah Khan , Lucas Stach , David Airlie , Oded Gabbay , Arnd Bergmann , Christoph Hellwig , Alex Williamson , Marek Szyprowski , Tomasz Figa , Mauro Carvalho Chehab References: <20221116102659.70287-1-david@redhat.com> <20221116102659.70287-17-david@redhat.com> <81fb0fa3-2e06-b765-56ac-a7d981194e59@redhat.com> From: Hans Verkuil Subject: Re: [PATCH mm-unstable v1 16/20] mm/frame-vector: remove FOLL_FORCE usage In-Reply-To: <81fb0fa3-2e06-b765-56ac-a7d981194e59@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On 27/11/2022 11:35, David Hildenbrand wrote: > On 16.11.22 11:26, David Hildenbrand wrote: >> FOLL_FORCE is really only for ptrace access. According to commit >> 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always >> writable"), get_vaddr_frames() currently pins all pages writable as a >> workaround for issues with read-only buffers. >> >> FOLL_FORCE, however, seems to be a legacy leftover as it predates >> commit 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are >> always writable"). Let's just remove it. >> >> Once the read-only buffer issue has been resolved, FOLL_WRITE could >> again be set depending on the DMA direction. >> >> Cc: Hans Verkuil >> Cc: Marek Szyprowski >> Cc: Tomasz Figa >> Cc: Marek Szyprowski >> Cc: Mauro Carvalho Chehab >> Signed-off-by: David Hildenbrand >> --- >>   drivers/media/common/videobuf2/frame_vector.c | 2 +- >>   1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c >> index 542dde9d2609..062e98148c53 100644 >> --- a/drivers/media/common/videobuf2/frame_vector.c >> +++ b/drivers/media/common/videobuf2/frame_vector.c >> @@ -50,7 +50,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, >>       start = untagged_addr(start); >>         ret = pin_user_pages_fast(start, nr_frames, >> -                  FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, >> +                  FOLL_WRITE | FOLL_LONGTERM, >>                     (struct page **)(vec->ptrs)); >>       if (ret > 0) { >>           vec->got_ref = true; > > > Hi Andrew, > > see the discussion at [1] regarding a conflict and how to proceed with > upstreaming. The conflict would be easy to resolve, however, also > the patch description doesn't make sense anymore with [1]. Might it be easier and less confusing if you post a v2 of this series with my patch first? That way it is clear that 1) my patch has to come first, and 2) that it is part of a single series and should be merged by the mm subsystem. Less chances of things going wrong that way. Just mention in the v2 cover letter that the first patch was added to make it easy to backport that fix without being hampered by merge conflicts if it was added after your frame_vector.c patch. Regards, Hans > > > On top of mm-unstable, reverting this patch and applying [1] gives me > an updated patch: > > > From 1e66c25f1467c1f1e5f275312f2c6df29308d4df Mon Sep 17 00:00:00 2001 > From: David Hildenbrand > Date: Wed, 16 Nov 2022 11:26:55 +0100 > Subject: [PATCH] mm/frame-vector: remove FOLL_FORCE usage > > GUP now supports reliable R/O long-term pinning in COW mappings, such > that we break COW early. MAP_SHARED VMAs only use the shared zeropage so > far in one corner case (DAXFS file with holes), which can be ignored > because GUP does not support long-term pinning in fsdax (see > check_vma_flags()). > > Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required > for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop > using FOLL_FORCE, which is really only for ptrace access. > > Reviewed-by: Daniel Vetter > Acked-by: Hans Verkuil > Cc: Hans Verkuil > Cc: Marek Szyprowski > Cc: Tomasz Figa > Cc: Marek Szyprowski > Cc: Mauro Carvalho Chehab > Signed-off-by: David Hildenbrand > --- >  drivers/media/common/videobuf2/frame_vector.c | 2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c > index aad72640f055..8606fdacf5b8 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -41,7 +41,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, bool write, >      int ret_pin_user_pages_fast = 0; >      int ret = 0; >      int err; > -    unsigned int gup_flags = FOLL_FORCE | FOLL_LONGTERM; > +    unsigned int gup_flags = FOLL_LONGTERM; >   >      if (nr_frames == 0) >          return 0;