linux-kernel - Re: [PATCH v3] dma-coherent: add support for multi coherent rmems per dev

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: <602448f1-60a9-41a1-85d2-1205250985d3@arm.com>
Date: Tue, 27 Feb 2024 14:31:54 +0000
From: Robin Murphy <robin.murphy@....com>
To: Howard Yen <howardyen@...gle.com>, Christoph Hellwig <hch@....de>
Cc: m.szyprowski@...sung.com, gregkh@...uxfoundation.org,
 andriy.shevchenko@...ux.intel.com, rafael@...nel.org, broonie@...nel.org,
 james@...iv.tech, james.clark@....com, masahiroy@...nel.org,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [PATCH v3] dma-coherent: add support for multi coherent rmems per
 dev

On 27/02/2024 1:39 pm, Howard Yen wrote:
> On Fri, Feb 23, 2024 at 2:37 PM Christoph Hellwig <hch@....de> wrote:
>>
>> On Wed, Feb 21, 2024 at 05:27:58PM +0800, Howard Yen wrote:
>>> The reason why I tried to propose this patch is that in the system I'm
>>> working on, where the driver utilizes the coherent reserved memory in
>>> the subsystem for DMA, which has limited memory space as its primary
>>> usage. During the execution of the driver, there is a possibility of
>>> encountering memory depletion scenarios with the primary one.
>>>
>>> To address this issue, I tried to create a patch that enables the
>>> coherent reserved memory driver to support multiple coherent reserved
>>> memory regions per device. This modification aims to provide the
>>> driver with the ability to search for memory from a secondary region
>>> if the primary memory is exhausted, and so on.
>>
>> This all seems pretty vague.  Can you point to your driver submission
>> and explain why it can't just use a larger region instead of multiple
>> smaller ones?
>>
> 
> The reason why it needs multiple regions is that in my system there is
> an always-on subsystem which includes a small size memory, and several
> functions need to run and occupy the memory from the small memory if
> they need to run on the always-on subsystem. These functions must
> allocate the memory from the small memory region, so that they can get
> benefit from the always-on subsystem. So the small memory is split for
> multiple functions which are satisfied with their generic use cases.

I don't really see how that aligns with what you've implemented, though. 
The coherent allocator doesn't have any notion of the caller's use-case, 
it's just going to allocate from wherever it happens to find space 
first. Thus even the calls which would somehow benefit from allocating 
from the "primary" region will have no way to guarantee that they will 
actually allocate from there if it's already been consumed by callers 
who didn't need that benefit but just happened to get there first.

Really that sounds like a case for having specific named memory-regions 
and managing them directly from the relevant driver, rather than trying 
to convince the generic dma-coherent abstraction to do things that don't 
really fit it. Otherwise I'd be slightly concerned that you're expecting 
to bake secret undocumented ABI into DMA API implementations where some 
particular order of allocations must guarantee a particular 
deterministic behaviour, which is really not something we want.

Thanks,
Robin.

> But in specific use cases, they required more memory than their
> pre-allocated memory region, so I tried to propose this patch to give
> it the ability to get the memory from another larger memory to solve
> the issue.
> 
> I'll upload the next version to show the modification in the driver.
> 
> ---
> Best Regards,
> 
> Howard