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 5.16:
#BUG 1
radeon_dpm_change_power_state_locked()
mutex_lock(>ring_lock); --> Li
n radeon_ring_lock(), because
"Lock A" has been already hold by radeon_ring_lock(), causing a possible
deadlock.
I find that "Wait X" is performed with a timeout MAX_SCHEDULE_TIMEOUT,
to relieve the possible deadlock; but 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
, 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
pu_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
On 2021/3/8 17:18, Chris Wilson wrote:
Quoting Jia-Ju Bai (2021-03-08 08:59:52)
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
It would not be EINVAL since that is used
When kcalloc() returns NULL to tsk or thread, no error code of
igt_threaded_blt() is returned.
To fix this bug, -ENOMEM is returned as error code.
Fixes: 0e99f939f08f ("drm/i915/selftests/blt: add some kthreads into the mix")
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
d
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
Fixes: 1fe3818d17c9 ("drm/i915/selftests: try to rein in alloc_smoke")
Reported-by: TOTE Robot
Signed-off-by:
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
rence 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
tatic analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/qxl/qxl_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 8b319ebbb0fb..fae18ef1ba59 100644
--- a/driver
:
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
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 find
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
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.
Ch
with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/drm_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3166026a1874..2486121a78d4 100644
--- a/drivers
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
nv40_sensor_setup() 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/nouveau/nvkm/subdev/therm
nv50_sensor_setup() 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/nouveau/nvkm/subdev/therm
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
by 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
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
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
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
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
broadsheetfb is a platform driver and it should not be used on x86.
It should be used only by single ARM PXA board, so adding the
dependency in Kconfig.
Signed-off-by: Jia-Ju Bai
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video
elect FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
Do you think it is okay?
Best wishes,
Jia-Ju Bai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
.
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
aiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/dr
00()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/gpu/drm/
sy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm
SAC) and checked by my code
review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/gpu/drm/drm_mm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 61a1c8e..5b9965d 100644
--- a/drivers/gpu/drm
Oh, sorry, I will send the patches for each driver.
Thanks,
Jia-Ju Bai
On 2017/10/9 16:17, Greg KH wrote:
On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, which
may sleep.
The function call paths
x them, the spinlock is released before gma_resume_pci, and it is acquired
again after gma_resume_pci.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
drivers/gpu/drm/gma500/power.c |2 ++
1 file changed, 2 insertions(+)
hese bugs are found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
drivers/pci/pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6078dfc..7b763a3 100644
--- a/drivers/pci/pci.
rs/pci/pci.c.
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
The driver may sleep under a spin lock, and the function call path is:
psbfb_2d_submit (acquire the lock by spin_lock_irqsave)
psb_2d_wait_available
psb_spank
msleep --> may sleep
To fix it, the "msleep" is replaced with "mdelay" in psb_spank.
Signed-off-by
39 matches
Mail list logo
