On Fri, Nov 11, 2022 at 03:31:15PM +0300, Dmitry Osipenko wrote: > On 11/11/22 15:05, Christian König wrote: > > Adding Dmitry as well. > > > > Am 11.11.22 um 12:45 schrieb Lukasz Wiecaszek: > >> The reason behind that patch is associated with videobuf2 subsystem > >> (or more genrally with v4l2 framework) and user created > >> dma buffers (udmabuf). In some circumstances > >> when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem > >> wants to use dma_buf_vmap() method on the attached dma buffer. > >> As udmabuf does not have .vmap operation implemented, > >> such dma_buf_vmap() natually fails. > >> > >> videobuf2_common: [cap-000000003473b2f1] __vb2_queue_alloc: allocated > >> 3 buffers, 1 plane(s) each > >> videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: buffer for > >> plane 0 changed > >> videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: failed to > >> map dmabuf for plane 0 > >> videobuf2_common: [cap-000000003473b2f1] __buf_prepare: buffer > >> preparation failed: -14 > >> > >> The patch itself seems to be strighforward. > >> It adds implementation of .vmap method to 'struct dma_buf_ops > >> udmabuf_ops'. > >> .vmap method itself uses vm_map_ram() to map pages linearly > >> into the kernel virtual address space (only if such mapping > >> hasn't been created yet). > > > > Of hand that sounds sane to me. > > > > You should probably mention somewhere in a code comment that the cached > > vaddr is protected by the reservation lock being taken. That's not > > necessary obvious to everybody. > > > > Apart from that looks good to me. > > Adding a comment won't hurt. > > We have the dma_resv_assert_held() in dma_buf_vmap() that will help > spotting a missing lock at runtime by developers. While the > dmbuf_ops->vmap() shouldn't be ever used directly by importers. > > -- > Best regards, > Dmitry > Give me some time guys. I need to prepare patch agains 6.1. And this is my first time, so now it hurts. Lukasz
