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]
Date: Tue, 27 Feb 2024 21:39:07 +0800
From: Howard Yen <howardyen@...gle.com>
To: Christoph Hellwig <hch@....de>
Cc: m.szyprowski@...sung.com, robin.murphy@....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 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.
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ