linux-kernel - Re: [RFC PATCH v1] dma-buf: heaps: move the verification of heap

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] [day] [month] [year] [list]

Message-ID: <f6dcb031-9668-4387-b279-958e344bdbaf@oppo.com>
Date: Wed, 5 Jun 2024 02:16:50 +0800
From: Hailong Liu <hailong.liu@...o.com>
To: John Stultz <jstultz@...gle.com>
CC: Sumit Semwal <sumit.semwal@...aro.org>, Benjamin Gaignard
	<benjamin.gaignard@...labora.com>, Brian Starkey <Brian.Starkey@....com>,
	"T.J. Mercier" <tjmercier@...gle.com>, Christian König
	<christian.koenig@....com>, <21cnbao@...il.com>,
	<linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
	<linaro-mm-sig@...ts.linaro.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1] dma-buf: heaps: move the verification of
 heap_flags to the corresponding heap

On 6/4/2024 11:33 PM, John Stultz wrote:
> On Mon, Jun 3, 2024 at 11:30 PM Hailong Liu <hailong.liu@...o.com> wrote:
>> On 6/4/2024 2:06 AM, John Stultz wrote:
>>> On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu <hailong.liu@...o.com> wrote:
>>>> We now aim to improve priority dma-buf allocation. Consider android
>>>> animations scene:
>>>>
>>>> when device is in low memory, Allocating dma-buf as animation
>>>> buffers enter direct_reclaimation, longer allocation time result in a
>>>> laggy UI. But if we know the usage of the dma-buf, we can use some
>>>> mechanisms to boost, e.g. animation-memory-pool.
>>>
>>> Can you generalize this a bit further? When would userland know to use
>>> this new flag?
>>> If it is aware, would it make sense to just use a separate heap name instead?
>>>
>>> (Also: These other mechanisms you mention should probably also be
>>> submitted upstream, however for upstream there's also the requirement
>>> that we have open users and are not just enabling proprietary blob
>>> userspace, which makes any changes to dma-buf heaps for out of tree
>>> code quite difficult)
>>>
>>>> However, dma-buf usage identification becomes a challenge. A potential
>>>> solution could be heap_flags. the use of heap_flags seems ugly and
>>>> contrary to the intended design as you said, How aboult extending
>>>> dma_heap_allocation_data as follows?
>>>>
>>>> struct dma_heap_allocation_data {
>>>>         __u64 len;
>>>>         __u32 fd;
>>>>         __u32 fd_flags;
>>>>         __u64 heap_flags;
>>>>         __u64 buf_flags: // buf usage
>>>> };
>>>
>>> This would affect the ABI (forcing a new ioctl number).  And it's
>>> unclear what flags you envision as buffer specific (rather than heap
>>> specific as this patch suggested).
>>>
>>> I think we need more details about the specific problem you're seeing
>>> and trying to resolve.
>> This patch mainly focuses on optimization for Android scenarios. Let’s
>> discuss it on the issue website.
>> Bug: 344501512
> 
> Ok, we can do that if you need.
> 
> But if this is ever going to go upstream (and it's more and more
> important that we minimize out of tree technical debt), conversations
> about how to generalize this will need to happen on the list.
> We need a more complete design and test results to convince upstream to accept. 
Thank you again for your suggestion.

Brs, 
Hailong.
> thanks
> -john