linux-kernel - Re: [PATCH 2/2] mm/frame-vec: use FOLL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d2f8e8a7-614d-18c8-9e2a-c604e5e54ce6@samsung.com>
Date:   Wed, 7 Oct 2020 12:47:10 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Daniel Vetter <daniel.vetter@...ll.ch>,
        Jason Gunthorpe <jgg@...pe.ca>
Cc:     DRI Development <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        John Hubbard <jhubbard@...dia.com>,
        Jérôme Glisse <jglisse@...hat.com>,
        Jan Kara <jack@...e.cz>,
        Dan Williams <dan.j.williams@...el.com>,
        Linux MM <linux-mm@...ck.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Pawel Osciak <pawel@...iak.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Tomasz Figa <tfiga@...omium.org>,
        Inki Dae <inki.dae@...sung.com>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <linux-media@...r.kernel.org>, Oded Gabbay <oded.gabbay@...il.com>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

Hi Daniel,

On 03.10.2020 11:40, Daniel Vetter wrote:
>> After he three places above should use pin_user_pages_fast(), then
>> this whole broken API should be moved into videobuf2-memops.c and a
>> big fat "THIS DOESN'T WORK" stuck on it.
>>
>> videobuf2 should probably use P2P DMA buf for this instead.
> Yup this should be done with dma_buf instead, and v4l has that.

Yes, V4L2 has dma_buf support NOW. That days, using so called V4L2 
USERPTR method was the only way to achieve zero copy buffer sharing 
between devices, so this is just a historical baggage. I've been 
actively involved in implementing that. I've tried to make it secure as 
much as possible assuming the limitation of that approach. With a few 
assumptions it works fine. Buffers are refcounted both by the 
vm_ops->open or by incrementing the refcount of the vm->file. This 
basically works with any sane driver, which doesn't free the mmaped 
buffer until the file is released. This is true for V4L2 and FBdev devices.

This API is considered as deprecated in V4L2 world, so I think 
supporting this hack can be removed one day as nowadays userspace should 
use dma buf.

 > ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland