Commen=
t # 8
on bug 10138=
7
from =
Carlo Caione
Just a better description of what's going on and a couple of q=
uestions.
When amdgpu_atombios_crtc_powergate_init() is called this triggers the pars=
ing
of the command table with index =3D=3D 13 (>> execute C5C0 (len 589, =
WS 0, PS 0)).
As already reported the parameter space used (struct
ENABLE_DISP_POWER_GATING_PARAMETERS_V2_1) is 32 bytes wide.
During the execution of this table several CALL_TABLE (op =3D=3D 82) are ex=
ecuted.=20
In particular we first just to table with index =3D=3D 78 (>> execute=
F166 (len
588, WS 0, PS 8)), then to table with index =3D=3D 51 (>> execute F44=
6 (len 465, WS
4, PS 4)) and finally to table with index =3D=3D 75 (>> execute F6CC =
(len 1330, WS
4, PS 0)) before finally reaching the EOT for table 13.
During the execution of table 75 a MOVE_PS is executed with a destination i=
ndex
=3D=3D 1, accessing ctx->ps[idx] and causing the stack corruption.
So either the atombios code is wrong or the atombios interpreter in the ker=
nel
is doing something wrong.
I also have a couple of questions / observations:
1) Table 75 has WS =3D=3D 4 and PS =3D=3D 0 and looking at the opcodes in t=
he table I
basically have only *_WS opcodes (MOVE_WS, TEST_WS, ADD_WS, etc...) and just
two *_PS instructions (MOVE_PS and OR_PS) that (guess what) are the
instructions causing the stack corruption. My guess here is that the opcodes
*_PS in the atombios are wrong and they should actually be *_WS opcodes.
2) Don't we need to allocate the size of the ps allocation struct for the
command table we are going to execute after a CALL_TABLE matching the ps si=
ze
in the table header? IIUC the code in the kernel, when we are jumping to a
different table ctx->ps is not being reallocated.
3) Could the point at (2) also be a problem in our case? Assuming that ps r=
ead
from the table header has something to do with the size of the parameter sp=
ace
(guessing here) Table 13 has PS =3D=3D 0, while table 75 has PS =3D=3D 4 wh=
ereas both
are using the same ctx->ps.