diff mbox series

[2/3] drm/msm: Allocate memory for disp snapshot with kvzalloc()

Message ID 20241014093605.2.I72441365ffe91f3dceb17db0a8ec976af8139590@changeid (mailing list archive)
State Not Applicable
Headers show
Series [1/3] drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() | expand

Commit Message

Douglas Anderson Oct. 14, 2024, 4:36 p.m. UTC
With the "drm/msm: add a display mmu fault handler" series [1] we saw
issues in the field where memory allocation was failing when
allocating space for registers in msm_disp_state_dump_regs().
Specifically we were seeing an order 5 allocation fail. It's not
surprising that order 5 allocations will sometimes fail after the
system has been up and running for a while.

There's no need here for contiguous memory. Change the allocation to
kvzalloc() which should make it much less likely to fail.

[1] https://lore.kernel.org/r/20240628214848.4075651-1-quic_abhinavk@quicinc.com/

Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Abhinav Kumar Oct. 14, 2024, 6:56 p.m. UTC | #1
On 10/14/2024 9:36 AM, Douglas Anderson wrote:
> With the "drm/msm: add a display mmu fault handler" series [1] we saw
> issues in the field where memory allocation was failing when
> allocating space for registers in msm_disp_state_dump_regs().
> Specifically we were seeing an order 5 allocation fail. It's not
> surprising that order 5 allocations will sometimes fail after the
> system has been up and running for a while.
> 
> There's no need here for contiguous memory. Change the allocation to
> kvzalloc() which should make it much less likely to fail.
> 
> [1] https://lore.kernel.org/r/20240628214848.4075651-1-quic_abhinavk@quicinc.com/
> 
> Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>   drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 

I had some doubts on how this issue happens considering that the devcore 
should automatically release the memory within 5 sec even if userspace 
had not read this. So there is no leak as such, its just that in a 
heavily loaded system, this can happen.

Fix looks okay to me,

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
diff mbox series

Patch

diff --git a/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c b/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
index bb149281d31f..4d55e3cf570f 100644
--- a/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
+++ b/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
@@ -26,7 +26,7 @@  static void msm_disp_state_dump_regs(u32 **reg, u32 aligned_len, void __iomem *b
 	end_addr = base_addr + aligned_len;
 
 	if (!(*reg))
-		*reg = kzalloc(len_padded, GFP_KERNEL);
+		*reg = kvzalloc(len_padded, GFP_KERNEL);
 
 	if (*reg)
 		dump_addr = *reg;
@@ -162,7 +162,7 @@  void msm_disp_state_free(void *data)
 
 	list_for_each_entry_safe(block, tmp, &disp_state->blocks, node) {
 		list_del(&block->node);
-		kfree(block->state);
+		kvfree(block->state);
 		kfree(block);
 	}