Re: [PATCH] media: videobuf2: revert "get_userptr: buffers are always writable"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/11/2022 10:35, David Hildenbrand wrote:
> 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.

That also works. Perhaps it's a better approach. If Andrew agrees, then I'll repost
my patch with a CC to linux-mm and Andrew.

Regards,

	Hans

> 
> 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?
> 




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux