linux-kernel - Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

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: <CAAFQd5DS1NxKh4OJ52T2AJNTHg6K2fnuDm5-GHzmUk-kjowf2w@mail.gmail.com>
Date:   Thu, 6 Jul 2017 22:31:57 +0900
From:   Tomasz Figa <tfiga@...omium.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Christoph Hellwig <hch@....de>,
        "open list:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joerg Roedel <joro@...tes.org>,
        Will Deacon <will.deacon@....com>,
        Vineet Gupta <vgupta@...opsys.com>,
        Hans-Christian Noren Egtvedt <egtvedt@...fundet.no>,
        Mitchel Humpherys <mitchelh@...eaurora.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Sakari Ailus <sakari.ailus@....fi>,
        Pawel Osciak <posciak@...omium.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa <tfiga@...omium.org> wrote:
>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tfiga@...omium.org> wrote:
>>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <arnd@...db.de> wrote:
>>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tfiga@...omium.org> wrote:
>
>>>
>>> I'd say that this is something that has been consistently tried to be
>>> avoided by V4L2 and that's why it's so tightly integrated with DMA
>>> mapping. IMHO re-implementing the code that's already there in
>>> videobuf2 again in the driver, only because, for no good reason
>>> mentioned as for now, having a loadable module providing DMA ops was
>>> disliked.
>>
>> Sorry, I intended to mean:
>>
>> IMHO re-implementing the code that's already there in videobuf2 again
>> in the driver, only because, for no good reason mentioned as for now,
>> having a loadable module providing DMA ops was disliked, would make no
>> sense.
>
> Why would we need to duplicate that code? I would expect that the videobuf2
> core can simply call the regular dma_mapping interfaces, and you handle the
> IOPTE generation at the point when the buffer is handed off from the core
> code to the device driver. Am I missing something?

Well, for example, the iommu-dma helpers already implement all the
IOVA management, SG iterations, IOMMU API calls, sanity checks and so
on. There is a significant amount of common code.

On the other hand, if it's strictly about base/dma-mapping, we might
not need it indeed. The driver could call iommu-dma helpers directly,
without the need to provide its own DMA ops. One caveat, though, we
are not able to obtain coherent (i.e. uncached) memory with this
approach, which might have some performance effects and complicates
the code, that would now need to flush caches even for some small
internal buffers.

Best regards,
Tomasz