All of lore.kernel.org
 help / color / mirror / Atom feed
From: <guangming.cao@mediatek.com>
To: "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>,
	"John Stultz" <john.stultz@linaro.org>,
	"Christian König" <christian.koenig@amd.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>
Cc: <wsd_upstream@mediatek.com>, 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>,
	Guangming <Guangming.Cao@mediatek.com>
Subject: [PATCH] dma-buf: dma-heap: Add a size limitation for allocation
Date: Fri, 17 Dec 2021 17:41:04 +0800	[thread overview]
Message-ID: <20211217094104.24977-1-guangming.cao@mediatek.com> (raw)

From: Guangming <Guangming.Cao@mediatek.com>

Currently, there is no size check for allocation.

If the alloc size is larger than DRAM, it will cause OOM issue.
Besides, if it runs on a process that won't be killed by OOM flow, it will
cause a kernel exception finally,  and we couldn't find the correct
memory usage by dma-buf dump api such as "dma_buf_debug_show" since the
allocation is still on going and the corresponding dmabuf is not exported.

However, it sounds not simple enough to adding a count to count how many
pages has been allocated before allocating done.
So adding a size limitation here to prevent this case.

Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..8b75998a106c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
 	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
 		return -EINVAL;
 
+	if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2)
+		return -EINVAL;
+
 	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
 				   heap_allocation->fd_flags,
 				   heap_allocation->heap_flags);
-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: <guangming.cao@mediatek.com>
To: "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>,
	"John Stultz" <john.stultz@linaro.org>,
	"Christian König" <christian.koenig@amd.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>
Cc: Guangming <Guangming.Cao@mediatek.com>,
	wsd_upstream@mediatek.com, Yunfei Wang <yf.wang@mediatek.com>,
	Libo Kang <libo.kang@mediatek.com>,
	Bo Song <bo.song@mediatek.com>,
	mingyuan ma <mingyuan.ma@mediatek.com>,
	jianjiao zeng <jianjiao.zeng@mediatek.com>
Subject: [PATCH] dma-buf: dma-heap: Add a size limitation for allocation
Date: Fri, 17 Dec 2021 17:41:04 +0800	[thread overview]
Message-ID: <20211217094104.24977-1-guangming.cao@mediatek.com> (raw)

From: Guangming <Guangming.Cao@mediatek.com>

Currently, there is no size check for allocation.

If the alloc size is larger than DRAM, it will cause OOM issue.
Besides, if it runs on a process that won't be killed by OOM flow, it will
cause a kernel exception finally,  and we couldn't find the correct
memory usage by dma-buf dump api such as "dma_buf_debug_show" since the
allocation is still on going and the corresponding dmabuf is not exported.

However, it sounds not simple enough to adding a count to count how many
pages has been allocated before allocating done.
So adding a size limitation here to prevent this case.

Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..8b75998a106c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
 	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
 		return -EINVAL;
 
+	if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2)
+		return -EINVAL;
+
 	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
 				   heap_allocation->fd_flags,
 				   heap_allocation->heap_flags);
-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: <guangming.cao@mediatek.com>
To: "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>,
	"John Stultz" <john.stultz@linaro.org>,
	"Christian König" <christian.koenig@amd.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>
Cc: <wsd_upstream@mediatek.com>, 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>,
	Guangming <Guangming.Cao@mediatek.com>
Subject: [PATCH] dma-buf: dma-heap: Add a size limitation for allocation
Date: Fri, 17 Dec 2021 17:41:04 +0800	[thread overview]
Message-ID: <20211217094104.24977-1-guangming.cao@mediatek.com> (raw)

From: Guangming <Guangming.Cao@mediatek.com>

Currently, there is no size check for allocation.

If the alloc size is larger than DRAM, it will cause OOM issue.
Besides, if it runs on a process that won't be killed by OOM flow, it will
cause a kernel exception finally,  and we couldn't find the correct
memory usage by dma-buf dump api such as "dma_buf_debug_show" since the
allocation is still on going and the corresponding dmabuf is not exported.

However, it sounds not simple enough to adding a count to count how many
pages has been allocated before allocating done.
So adding a size limitation here to prevent this case.

Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..8b75998a106c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
 	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
 		return -EINVAL;
 
+	if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2)
+		return -EINVAL;
+
 	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
 				   heap_allocation->fd_flags,
 				   heap_allocation->heap_flags);
-- 
2.17.1


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

WARNING: multiple messages have this Message-ID (diff)
From: <guangming.cao@mediatek.com>
To: "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>,
	"John Stultz" <john.stultz@linaro.org>,
	"Christian König" <christian.koenig@amd.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>
Cc: <wsd_upstream@mediatek.com>, 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>,
	Guangming <Guangming.Cao@mediatek.com>
Subject: [PATCH] dma-buf: dma-heap: Add a size limitation for allocation
Date: Fri, 17 Dec 2021 17:41:04 +0800	[thread overview]
Message-ID: <20211217094104.24977-1-guangming.cao@mediatek.com> (raw)

From: Guangming <Guangming.Cao@mediatek.com>

Currently, there is no size check for allocation.

If the alloc size is larger than DRAM, it will cause OOM issue.
Besides, if it runs on a process that won't be killed by OOM flow, it will
cause a kernel exception finally,  and we couldn't find the correct
memory usage by dma-buf dump api such as "dma_buf_debug_show" since the
allocation is still on going and the corresponding dmabuf is not exported.

However, it sounds not simple enough to adding a count to count how many
pages has been allocated before allocating done.
So adding a size limitation here to prevent this case.

Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..8b75998a106c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
 	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
 		return -EINVAL;
 
+	if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2)
+		return -EINVAL;
+
 	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
 				   heap_allocation->fd_flags,
 				   heap_allocation->heap_flags);
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2021-12-17  9:40 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  9:41 guangming.cao [this message]
2021-12-17  9:41 ` [PATCH] dma-buf: dma-heap: Add a size limitation for allocation guangming.cao
2021-12-17  9:41 ` guangming.cao
2021-12-17  9:41 ` guangming.cao
2021-12-27  9:51 ` [PATCH v2] dma-buf: dma-heap: Add a size check " guangming.cao
2021-12-27  9:51   ` guangming.cao
2021-12-27  9:51   ` guangming.cao
2021-12-27  9:51   ` guangming.cao
2022-01-03 18:57   ` John Stultz
2022-01-03 18:57     ` John Stultz
2022-01-03 18:57     ` John Stultz
2022-01-03 18:57     ` John Stultz
2022-01-04  7:47     ` Christian König
2022-01-04  7:47       ` Christian König
2022-01-04  7:47       ` Christian König
2022-01-04  7:47       ` Christian König
2022-01-04  8:44       ` Guangming.Cao
2022-01-04  8:44         ` Guangming.Cao
2022-01-04  8:44         ` Guangming.Cao
2022-01-05  6:36       ` guangming.cao
2022-01-05  6:36         ` guangming.cao
2022-01-05  6:36         ` guangming.cao
2022-01-05  6:36         ` guangming.cao
2022-01-13 10:50         ` Sumit Semwal
2022-01-13 10:50           ` Sumit Semwal
2022-01-13 10:50           ` Sumit Semwal
2022-01-13 10:50           ` Sumit Semwal
2022-01-13 12:34           ` [PATCH v3] " guangming.cao
2022-01-13 12:34             ` guangming.cao
2022-01-13 12:34             ` guangming.cao
2022-01-13 12:34             ` guangming.cao
2022-01-13 12:57             ` Ruhl, Michael J
2022-01-13 12:57               ` Ruhl, Michael J
2022-01-13 12:57               ` Ruhl, Michael J
2022-01-13 12:57               ` Ruhl, Michael J
2022-01-13 13:00               ` Ruhl, Michael J
2022-01-13 13:00                 ` Ruhl, Michael J
2022-01-13 13:00                 ` Ruhl, Michael J
2022-01-13 13:00                 ` Ruhl, Michael J
2022-01-13 13:05                 ` Christian König
2022-01-13 13:05                   ` Christian König
2022-01-13 13:05                   ` Christian König
2022-01-13 13:05                   ` Christian König
2022-01-13 23:26                   ` John Stultz
2022-01-13 23:26                     ` John Stultz
2022-01-13 23:26                     ` John Stultz
2022-01-13 23:26                     ` John Stultz
2022-01-14  7:16                     ` Christian König
2022-01-14  7:16                       ` Christian König
2022-01-14  7:16                       ` Christian König
2022-01-14  7:16                       ` Christian König
2022-01-14 12:05                       ` Guangming.Cao
2022-01-14 12:05                         ` Guangming.Cao
2022-01-14 12:05                         ` Guangming.Cao
2022-01-15  1:17                         ` John Stultz
2022-01-15  1:17                           ` John Stultz
2022-01-15  1:17                           ` John Stultz
2022-01-15  1:17                           ` John Stultz
2022-01-19  9:59                           ` Guangming.Cao
2022-01-19  9:59                             ` Guangming.Cao
2022-01-19  9:59                             ` Guangming.Cao
2022-01-19 20:37                             ` John Stultz
2022-01-19 20:37                               ` John Stultz
2022-01-19 20:37                               ` John Stultz
2022-01-19 20:37                               ` John Stultz
2022-01-20  3:34                               ` [PATCH v4] dma-buf: system_heap: " guangming.cao
2022-01-20  3:34                                 ` guangming.cao
2022-01-20  3:34                                 ` guangming.cao
2022-01-20  3:34                                 ` guangming.cao
2022-01-20  3:48                                 ` John Stultz
2022-01-20  3:48                                   ` John Stultz
2022-01-20  3:48                                   ` John Stultz
2022-01-20  3:48                                   ` John Stultz
2022-01-20  7:08                                   ` [PATCH v5] " guangming.cao
2022-01-20  7:08                                     ` guangming.cao
2022-01-20  7:08                                     ` guangming.cao
2022-01-20  7:08                                     ` guangming.cao
2022-01-20  8:27                                     ` Christian König
2022-01-20  8:27                                       ` Christian König
2022-01-20  8:27                                       ` Christian König
2022-01-20  8:27                                       ` Christian König
2022-01-20  8:52                                       ` [PATCH v6] " guangming.cao
2022-01-20  8:52                                         ` guangming.cao
2022-01-20  8:52                                         ` guangming.cao
2022-01-20  8:52                                         ` guangming.cao
2022-01-20 10:00                                         ` [PATCH v6 RESEND] " guangming.cao
2022-01-20 10:00                                           ` guangming.cao
2022-01-20 10:00                                           ` guangming.cao
2022-01-20 10:00                                           ` guangming.cao
2022-01-20 10:22                                           ` Christian König
2022-01-20 10:22                                             ` Christian König
2022-01-20 10:22                                             ` Christian König
2022-01-20 10:22                                             ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211217094104.24977-1-guangming.cao@mediatek.com \
    --to=guangming.cao@mediatek.com \
    --cc=Brian.Starkey@arm.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=bo.song@mediatek.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jianjiao.zeng@mediatek.com \
    --cc=john.stultz@linaro.org \
    --cc=labbott@redhat.com \
    --cc=libo.kang@mediatek.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lmark@codeaurora.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mingyuan.ma@mediatek.com \
    --cc=sumit.semwal@linaro.org \
    --cc=wsd_upstream@mediatek.com \
    --cc=yf.wang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.