Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation

From: "Christian König" <christian.koenig@amd.com>
To: John Stultz <john.stultz@linaro.org>, guangming.cao@mediatek.com
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Liam Mark <lmark@codeaurora.org>,
	Laura Abbott <labbott@redhat.com>,
	Brian Starkey <Brian.Starkey@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"open list:DMA-BUF HEAPS FRAMEWORK" <linux-media@vger.kernel.org>,
	"open list:DMA-BUF HEAPS FRAMEWORK"
	<dri-devel@lists.freedesktop.org>,
	"moderated list:DMA-BUF HEAPS FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	open list <linux-kernel@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Bo Song <bo.song@mediatek.com>,
	Libo Kang <libo.kang@mediatek.com>,
	jianjiao zeng <jianjiao.zeng@mediatek.com>,
	mingyuan ma <mingyuan.ma@mediatek.com>,
	Yunfei Wang <yf.wang@mediatek.com>,
	wsd_upstream@mediatek.com
Subject: Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
Date: Tue, 4 Jan 2022 08:47:54 +0100	[thread overview]
Message-ID: <c05749d0-4c24-8763-a459-27257b2524ed@amd.com> (raw)
In-Reply-To: <CALAqxLVA4jUk-2o28RZobrPDUnuXfV1xN77Pt8Pu1o27V3aUQQ@mail.gmail.com>

Am 03.01.22 um 19:57 schrieb John Stultz:
> On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao@mediatek.com> wrote:
>> From: Guangming <Guangming.Cao@mediatek.com>
>>
> Thanks for submitting this!
>
>> Add a size check for allcation since the allocation size is
> nit: "allocation" above.
>
>> always less than the total DRAM size.
> In general, it might be good to add more context to the commit message
> to better answer *why* this change is needed rather than what the
> change is doing.  ie: What negative thing happens without this change?
> And so how does this change avoid or improve things?

Completely agree, just one little addition: Could you also add this why 
as comment to the code?

When we stumble over this five years from now it is absolutely not 
obvious why we do this.

Thanks,
Christian.

>
>
>> Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
>> Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
>> ---
>> v2: 1. update size limitation as total_dram page size.
>>      2. update commit message
>> ---
>>   drivers/dma-buf/dma-heap.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
>> index 56bf5ad01ad5..e39d2be98d69 100644
>> --- a/drivers/dma-buf/dma-heap.c
>> +++ b/drivers/dma-buf/dma-heap.c
>> @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>>          struct dma_buf *dmabuf;
>>          int fd;
>>
>> +       if (len / PAGE_SIZE > totalram_pages())
>> +               return -EINVAL;
> This seems sane. I know ION used to have some 1/2 of memory cap to
> avoid unnecessary memory pressure on crazy allocations.
>
> Could you send again with an improved commit message?
>
> thanks
> -john

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek