From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH mm-unstable v1 16/20] mm/frame-vector: remove FOLL_FORCE usage Date: Sun, 27 Nov 2022 11:35:09 +0100 Message-ID: <81fb0fa3-2e06-b765-56ac-a7d981194e59@redhat.com> References: <20221116102659.70287-1-david@redhat.com> <20221116102659.70287-17-david@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Subject:From:References:Cc:To: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G1LxGg6lThxykOMDsBO+gkd4mNaE+E0lcZrZBvY3ckQ=; b=aDz5WzCYsLrzzS tC2pC/WUtCjXxhec/w/cIgT1CJBv+beGMBFsiJgtcbdO4Zzmqm93B2DUvr4+tCVzRNyFTy2G7MYws s3HIyytbcaHf/PLTPgg0zBfwelltgxJUHwS6yn6geWtXUwFI9hBBKk+g48oMV2qU4u3wGXHitBCNN IzcYPO1J2FonHG3e6qgbPxDxCACX+MkRv3rudtK39mjOERNWY6Zx19MqsAFoslmB3A+o5/gXOCcF1 H9h7H6yFD9/nAEGAMKoo3aIFNfYbB451YbtjdjGQmVk8YmjmH/dO+7j6cnWjEXK4U64kZ7dW6GuAZ EWasNbakolfhRfkun4ZQ==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669545316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a/FKhEJUKr4Au5jEDV0nA39boCfv1uOAmeL78/XZzlw=; b=ZiWJIwXTHsjSEHq8nmAktEDguAR5ZBAbFagwztjoL15CYq9GXM4SxOqpaYXHRKTbS1pN9e jPSH3sxop7DDk2Qsf6e7hqox/pF9rAGnzh/0LlLNO+yvnwwdwmmRAuewqVMMGL4mV+x151 w2ahB7HNB+KnDfIPqHjmPpm7Q2xo68A= In-Reply-To: <20221116102659.70287-17-david@redhat.com> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-um" Errors-To: linux-um-bounces+glud-user-mode-linux-devel=m.gmane-mx.org@lists.infradead.org Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-kernel@vger.kernel.org, Hans Verkuil , 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 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]. 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; -- 2.38.1 Please let me know how you want to proceed. Ideally, you'd pick up [1] and apply this updated patch. Also, please tell me if I should send this updated patch in a separate mail (e.g., as reply to this mail). [1] https://lkml.kernel.org/r/71bdd3cf-b044-3f12-df58-7c16d5749587@xs4all.nl -- Thanks, David / dhildenb