media: mediatek: vcodec: mark vdec_vp9_slice_map_counts_eob_coef noinline
Subsystems (3)
PATCH 1/1 media: mediatek: vcodec: mark vdec_vp9_slice_map_counts_eob_coef noinline
From: Arnd Bergmann <[email protected]>
With KASAN enabled, clang fails to optimize the inline version of vdec_vp9_slice_map_counts_eob_coef() properly, leading to kilobytes of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]
This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release.
Marking the function as noinline_for_stack is harmless here and avoids the problem completely.
---
I have not come to a conclusion on how exactly clang fails to do this right, but can provide the .config and/or preprocessed source files and command line if we think this should be fixed in clang.
--- .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +2 -1
@@ -1188,7 +1188,8 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,return ret; } -static +/* clang stack usage explodes if this is inlined */ +static noinline_for_stack void vdec_vp9_slice_map_counts_eob_coef(unsigned int i, unsigned int j, unsigned int k,struct vdec_vp9_slice_frame_counts *counts,struct v4l2_vp9_frame_symbol_counts *counts_helper)
Signature · 1 line
2.39.5
Quoted 11 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef()properly, leading to kilobytes of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release.
Quoted 8 lines
Marking the function as
noinline_for_stackis harmless here and avoids the problem completely.Signed-off-by Arnd Bergmann <[email protected]>---
I have not come to a conclusion on how exactly clang fails to do this right, but can provide the .config and/or preprocessed source files and command line if we think this should be fixed in clang.
I think this might be related to the issue I reported to upstream LLVM, as a regression within the past couple of weeks:
https://github.com/llvm/llvm-project/issues/111903
If this is a reasonable workaround, it might be worth doing but I will probably wait until after the LLVM Developers Meeting next week to ping the thread to have a better chance of visibility. If we want to work around this in the kernel, we should Cc stable, as this warning is present there too.
Quoted 21 lines
--- .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +2
-1@@ -1188,7 +1188,8 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,return ret; } -static +/* clang stack usage explodes if this is inlined */ +static noinline_for_stack void vdec_vp9_slice_map_counts_eob_coef(unsigned int i, unsigned int j, unsigned int k,struct vdec_vp9_slice_frame_counts *counts,struct v4l2_vp9_frame_symbol_counts *counts_helper)Signature · 1 line
2.39.5
Quoted 8 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef()properly, leading to kilobytes of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]
Quoted 7 lines
This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release.
Marking the function as
noinline_for_stackis harmless here and avoids the problem completely.Signed-off-by Arnd Bergmann <[email protected]>
Unfortunately, I have seen no moment on my upstream report and this warning is breaking allmodconfig builds because of -Werror. Can this be applied as a workaround for now (preferrably with a Cc: stable on it)?
Quoted 25 lines
---
I have not come to a conclusion on how exactly clang fails to do this right, but can provide the .config and/or preprocessed source files and command line if we think this should be fixed in clang.--- .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +2
-1@@ -1188,7 +1188,8 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,return ret; } -static +/* clang stack usage explodes if this is inlined */ +static noinline_for_stack void vdec_vp9_slice_map_counts_eob_coef(unsigned int i, unsigned int j, unsigned int k,struct vdec_vp9_slice_frame_counts *counts,struct v4l2_vp9_frame_symbol_counts *counts_helper)Signature · 1 line
2.39.5
Hey Nathan,
Quoted 15 lines · Nathan Chancellor
Quoted 14 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef()properly, leading to kilobytes of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release.
Marking the function as
noinline_for_stackis harmless here and avoids the problem completely.
Quoted 7 lines
Quoted 1 line
Signed-off-by Arnd Bergmann <[email protected]>Unfortunately, I have seen no moment on my upstream report and this warning is breaking allmodconfig builds because of -Werror. Can this be applied as a workaround for now (preferrably with a Cc: stable on it)?
Reviewed-by Nathan Chancellor <[email protected]>
I'll handle it asap, it will be part of 6.13
Regards,
Sebastian
Quoted 27 lines
Quoted 26 lines
---
I have not come to a conclusion on how exactly clang fails to do this right, but can provide the .config and/or preprocessed source files and command line if we think this should be fixed in clang.--- .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +2
-2@@ -1188,7 +1188,8 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,return ret; } -static +/* clang stack usage explodes if this is inlined */ +static noinline_for_stack void vdec_vp9_slice_map_counts_eob_coef(unsigned int i, unsigned int j, unsigned int k,struct vdec_vp9_slice_frame_counts *counts,struct v4l2_vp9_frame_symbol_counts *counts_helper) --2.39.5
Hi Sebastian,
Quoted 20 lines · Sebastian Fricke
Hey Nathan,
Quoted 17 lines · Nathan Chancellor
Quoted 15 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef()properly, leading to kilobytes of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release.
Marking the function as
noinline_for_stackis harmless here and avoids the problem completely.Signed-off-by Arnd Bergmann <[email protected]>
Quoted 7 lines
Quoted 5 lines
Unfortunately, I have seen no moment on my upstream report and this warning is breaking allmodconfig builds because of -Werror. Can this be applied as a workaround for now (preferrably with a Cc: stable on it)?
Reviewed-by Nathan Chancellor <[email protected]>I'll handle it asap, it will be part of 6.13
Is there any update here? I don't see this patch applied in -next.
Cheers,
Nathan
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
---
I have not come to a conclusion on how exactly clang fails to do this right, but can provide the .config and/or preprocessed source files and command line if we think this should be fixed in clang.--- .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +2
-2@@ -1188,7 +1188,8 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,return ret; } -static +/* clang stack usage explodes if this is inlined */ +static noinline_for_stack void vdec_vp9_slice_map_counts_eob_coef(unsigned int i, unsigned int j, unsigned int k,struct vdec_vp9_slice_frame_counts *counts,struct v4l2_vp9_frame_symbol_counts *counts_helper) --2.39.5
Hey Nathan,
Quoted 27 lines · Nathan Chancellor
Hi Sebastian,
Quoted 24 lines · Sebastian Fricke
Hey Nathan,
Quoted 21 lines · Nathan Chancellor
Quoted 8 lines · Arnd Bergmann
From: Arnd Bergmann <[email protected]>
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef()properly, leading to kilobytes of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]Quoted 7 lines
This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release.
Marking the function as
noinline_for_stackis harmless here and avoids the problem completely.Signed-off-by Arnd Bergmann <[email protected]>Unfortunately, I have seen no moment on my upstream report and this warning is breaking allmodconfig builds because of -Werror. Can this be applied as a workaround for now (preferrably with a Cc: stable on it)?
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Reviewed-by Nathan Chancellor <[email protected]>I'll handle it asap, it will be part of 6.13
Is there any update here? I don't see this patch applied in -next.
I have sent out the PR and it has been applied to the -fixes branch in the media tree, due to the holiday period there might be some delays but I expect the change to soon land in Linux-next.
Quoted 3 lines
Cheers,
Nathan
Regards,
Sebastian
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
---
I have not come to a conclusion on how exactly clang fails to do this right, but can provide the .config and/or preprocessed source files and command line if we think this should be fixed in clang.--- .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +0
-0@@ -1188,7 +1188,8 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,return ret; }
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c +2
-2-static +/* clang stack usage explodes if this is inlined */ +static noinline_for_stack void vdec_vp9_slice_map_counts_eob_coef(unsigned int i, unsigned int j, unsigned int k,struct vdec_vp9_slice_frame_counts *counts,struct v4l2_vp9_frame_symbol_counts *counts_helper) --2.39.5
Sebastian Fricke
Consultant Software Engineer
Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK Registered in England & Wales no 5513718.
Quoted 3 lines · Sebastian Fricke
I have sent out the PR and it has been applied to the -fixes branch in the media tree, due to the holiday period there might be some delays but I expect the change to soon land in Linux-next.
Ah, thanks a lot! I was looking at the main media tree's fixes branch but I see it is only in the media-pending tree right now:
As long as it is on its way, that's all that matters to me. Appreciate you getting that process moving!
Cheers,
Nathan