On 14/11/2024 16:04, Mario Limonciello wrote:
Although it's really useful information for AMD people, the Jira
shouldn't be in the "title" of the commit message.
"If" we want to get into the habit of including this information for
display code we should come up with a prescriptive field that goes
into the commit message during promotion and it should be part of all
patches in the promotion that have it.
Something like this:
AMD-Jira: SWDEV-476969
Probably need to align that with other stakeholders though before
starting that way.
On 11/14/2024 08:37, Zaeem Mohamed wrote:
[why]
Prevent index-out-of-bounds due to requiring cursor overlay when
plane_count is MAX_SURFACES.
[how]
Bounds check on plane_count when requiring overlay cursor.
Any link to failing bugs or anything like that you can include?
Hi Mario,
About this question, these are the related issues:
- Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3693
- Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3594
You can find more details in previous iterations related to this bug:
-
https://lore.kernel.org/amd-gfx/575d66c7-e77d-42ea-acbf-412d6e508a0b@xxxxxxxxxx/
- https://lore.kernel.org/amd-gfx/20240925154324.348774-1-mwen@xxxxxxxxxx/
Co-developed-by: Melissa Wen <mwen@xxxxxxxxxx>
Signed-off-by: Zaeem Mohamed <zaeem.mohamed@xxxxxxx>
You're missing Melisaa's SoB for a co-developed patch.
IIRC this should fail checkpatch.
I already mentioned before, I don't think I actually co-dev this code,
so Zaeem can remove it in the next iteration.
---
BTW, about the implementation:
As I don't have the proper environment, I asked reporters to check this
patch up and it doesn't help prevent interface freeze.
It seems to prevent the out of bounds bug but is causing a page fault now:
kernel: BUG: unable to handle page fault for address: 000000000174e354
From their feedback, I found curious that MAX_SURFACES -> 4 prevents
the freeze but not completely solve the problem.
MAX_SURFACES -> 6 solves it, what let me consider that the MAX_SURFACES
vs MAX_SURFACE_NUM vs MAX_PLANE mismatch might be related.
I'm going to analyzing the logs but you can find more details here:
https://gitlab.freedesktop.org/drm/amd/-/issues/3693#note_2658994
BR,
Melissa Wen
---
amdgpu_dm/amdgpu_dm.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/amdgpu_dm/amdgpu_dm.c b/amdgpu_dm/amdgpu_dm.c
index 97e0a1bbba..964497c613 100644
--- a/amdgpu_dm/amdgpu_dm.c
+++ b/amdgpu_dm/amdgpu_dm.c
@@ -11821,8 +11821,16 @@ static int amdgpu_dm_atomic_check(struct
drm_device *dev,
/* Overlay cusor not subject to native cursor
restrictions */
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
- if (dm_new_crtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE)
+ if (dm_new_crtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE) {
+ if (dc->current_state->stream_status->plane_count >
MAX_SURFACES) {
+ drm_dbg_driver(crtc->dev,
+ "Can't enable cursor plane with %d planes\n",
MAX_SURFACES);
+ ret = -EINVAL;
+ goto fail;
+ }
+
continue;
+ }
/* Check if rotation or scaling is enabled on DCN401 */
if ((drm_plane_mask(crtc->cursor) &
new_crtc_state->plane_mask) &&
