On 24.11.22 10:13, Hans Verkuil wrote:
On 24/11/2022 09:45, David Hildenbrand wrote:
On 24.11.22 09:29, Hans Verkuil wrote:
Commit 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are
always writable") caused problems in a corner case (passing read-only
shmem memory as a userptr). So revert this patch.
The original problem for which that commit was originally made is
something that I could not reproduce after reverting it. So just go
back to the way it was for many years, and if problems arise in
the future, then another approach should be taken to resolve it.
This patch is based on a patch from Hirokazu.
Fixes: 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always writable")
Signed-off-by: Hirokazu Honda <hiroh@xxxxxxxxxxxx>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xxxxxxxxx>
---
Regarding possible merge conflicts with the FOLL_FORCE patch [1] that's already in -next, would it make sense to base this patch on the FOLL_FORCE patch and routing it through the -mm tree? Or what's
the best way to move forward?
CCing Andrew
[1] https://lkml.kernel.org/r/20221116102659.70287-17-david@xxxxxxxxxx
My preference would be to apply the removal of FOLL_FORCE *after* this
patch has been merged. This patch will likely be something that will be
backported to older kernels as well, and that's easier to do if it is
applied before your patch.
I think it is best to apply your patch for this after v6.2-rc1 is released.
If you post a patch removing FOLL_FORCE to linux-media once v6.2-rc1 is released,
then I can ensure it will be merged in a later v6.2-rcX.
Such dependencies with the -MM tree usually imply trouble. :/
There are two ways:
1) Andrew picks up your patch and we rebase my patch based on yours. All
goes in via the -mm tree in -rc1.
2) Andrew drops my patch and you apply the rebased patch later.
Applying patches after v6.2-rc1 doesn't really give them the chance to
lurk in -next for a longer time, and it kind-of feels wrong for
something that doesn't have a fixed tag attached. But I don't care as
long as we don't unnecessarily delay the FOLL_FORCE cleanup from getting
merged.
@Andrew?
--
Thanks,
David / dhildenb
