ode properly.
But that happens so rarely and the driver is not developed further
that we decided to not address this any more.
Ah, okay.
Regards,
Christian.
Am 01.02.22 um 08:40 schrieb Jia-Ju Bai:
Hello,
My static analysis tool reports a possible deadlock in the radeon
driver in Linux
I think this timeout can cause
inefficient execution.
I am not quite sure whether these possible problems are real and how to
fix them if they are real.
Any feedback would be appreciated, thanks :)
Best wishes,
Jia-Ju Bai
Hello,
Could you please provide the feedback to my previous report?
Thanks a lot :)
Best wishes,
Jia-Ju Bai
On 2021/9/15 17:39, Jia-Ju Bai wrote:
Hello,
My static analysis tool reports a possible ABBA deadlock in the amdgpu
driver in Linux 5.10:
amdgpu_debugfs_process_reg_op
idx_mutex); --> Line 3697 (Lock A)
When amdgpu_debugfs_process_reg_op() and
amdgpu_set_power_dpm_force_performance_level() are concurrently
executed, the deadlock can occur.
I am not quite sure whether this possible deadlock is real and how to
fix it if it is real.
Any feedback would be appreciated, thanks :)
Reported-by: TOTE Robot
Best wishes,
Jia-Ju Bai
Add error return code in error hanlding code of amdgpu_acpi_init().
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu
When bitmap_empty() or feature->feature_num triggers an error,
no error return code of smu_v11_0_set_allowed_mask() is assigned.
To fix this bug, ret is assigned with -EINVAL as error return code.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/pm/swsmu/sm
may occur.
To fix this bug, connector->encoder is checked before being used.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
from WREG32() or RREG32()?
Best wishes,
Jia-Ju Bai
On 2018/9/15 17:10, Koenig, Christian wrote:
amdgpu_ring_alloc() does call amdgpu_uvd_begin_use(), but never in the
call chain you proposed.
Thinking about it I actually don't see a way a statically analysis
could ever figure that out.
igure that out.
Okay, thanks for your explanation :)
Besides, I find that amdgpu_virt_kiq_rreg() calls msleep(), so mdelay()
should be used instead.
Best wishes,
Jia-Ju Bai
Am 15.09.2018 11:18 schrieb Jia-Ju Bai :
Sorry, I am still not clear why the call chain I proposed is incorrect...
I f
amdgpu_ring_alloc() never calls amdgpu_uvd_ring_begin_use()?
Thanks in advance.
Best wishes,
Jia-Ju Bai
Regards,
Christian.
Am 15.09.2018 10:59 schrieb Jia-Ju Bai :
The driver may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.17 are:
[FUNC
:
amdgpu_mm_wreg in dce_v6_0_audio_endpt_rreg
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c, 125:
_raw_spin_lock_irqsave in dce_v6_0_audio_endpt_rreg
Note that [FUNC_PTR] means a function pointer call is used.
These bugs are found by my static analysis tool DSAC.
Best wishes,
Jia-Ju Bai
myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/r600.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e06e2d8feab3..de5f6d9f251e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b
r300_asic_reset() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon
si_pcie_gen3_enable() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/si.c | 2 +-
1
r100_asic_reset() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon
rs600_asic_reset() is never called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon
radeon_test_ring_sync() and radeon_test_ring_sync2() are never
called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
cik_pcie_gen3_enable() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/cik.c | 2 +-
1
.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/amdgpu/cik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 0df22030e713..5b7fab2c2008 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm
19 matches
Mail list logo