Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 5/10/2024 4:24 AM, Jani Nikula wrote:
On Fri, 10 May 2024, "Lin, Wayne" <Wayne.Lin@xxxxxxx> wrote:
[Public]

-----Original Message-----
From: Limonciello, Mario <Mario.Limonciello@xxxxxxx>
Sent: Friday, May 10, 2024 3:18 AM
To: Linux regressions mailing list <regressions@xxxxxxxxxxxxxxx>; Wentland, Harry
<Harry.Wentland@xxxxxxx>; Lin, Wayne <Wayne.Lin@xxxxxxx>
Cc: lyude@xxxxxxxxxx; imre.deak@xxxxxxxxx; Leon Weiß <leon.weiss@ruhr-uni-
bochum.de>; stable@xxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; amd-
gfx@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH] drm/mst: Fix NULL pointer dereference at
drm_dp_add_payload_part2

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:
On 18.04.24 21:43, Harry Wentland wrote:
On 2024-03-07 01:29, Wayne Lin wrote:
[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement") accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
drm_dp_add_payload_part2") which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input
parameter 'state' for drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Reported-by: Leon Weiß <leon.weiss@xxxxxxxxxxxxxxxxxx>
Link:
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.c
amel@xxxxxxxxxxxxxxxxxx/
Cc: lyude@xxxxxxxxxx
Cc: imre.deak@xxxxxxxxx
Cc: stable@xxxxxxxxxxxxxxx
Cc: regressions@xxxxxxxxxxxxxxx
Signed-off-by: Wayne Lin <Wayne.Lin@xxxxxxx>

I haven't been deep in MST code in a while but this all looks pretty
straightforward and good.

Reviewed-by: Harry Wentland <harry.wentland@xxxxxxx>

Hmmm, that was three weeks ago, but it seems since then nothing
happened to fix the linked regression through this or some other
patch. Is there a reason? The build failure report from the CI maybe?

It touches files outside of amd but only has an ack from AMD.  I think we
/probably/ want an ack from i915 and nouveau to take it through.

Thanks, Mario!

Hi Thorsten,
Yeah, like what Mario said. Would also like to have ack from i915 and nouveau.

It usually works better if you Cc the folks you want an ack from! ;)

Acked-by: Jani Nikula <jani.nikula@xxxxxxxxx>


Thanks! Can someone with commit permissions take this to drm-misc?




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux