On 01/15/2025 09:34 AM, Josh Poimboeuf wrote:
On Sat, Jan 11, 2025 at 02:57:42PM +0800, Tiezhu Yang wrote:
Hi Josh and Peter,
On 12/17/2024 09:08 AM, Tiezhu Yang wrote:
This version is based on tip/tip.git objtool/core branch [1], add some weak
and arch-specific functions to make the generic
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/os_types.h | 7 +++
1 file changed, 7
to only use ASSERT_BUG()
and SPL_ASSERT_BUG() directly after doing the following two steps:
(1) Add ASSERT_BUG() macro definition
(2) Add SPL_ASSERT_BUG() macro definition
This version is based on 6.13-rc7, tested on x86 and LoongArch.
Tiezhu Yang (3):
drm/amd/display: Add ASSERT_BUG() macro
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add SPL_ASSERT_BUG() macro definition
to harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/spl/spl_debug.h | 11 +++
1 file
On 01/14/2025 04:29 PM, Huacai Chen wrote:
Hi, Tiezhu,
On Tue, Jan 14, 2025 at 2:16 PM Tiezhu Yang wrote:
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions
undefined behavior, so use the new added ASSERT_BUG()
and SPL_ASSERT_BUG() to stop the control flow if the divisior is zero.
Suggested-by: Nathan Chancellor
Suggested-by: Xi Ruoyao
Suggested-by: Rui Wang
Signed-off-by: Tiezhu Yang
Link: https://lore.kernel.org/lkml/20241220223403.GA2605890@ax162
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add SPL_ASSERT_BUG() macro definition
to harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/spl/spl_debug.h | 9 +
1 file
to only use ASSERT_BUG()
and SPL_ASSERT_BUG() directly after doing the following two steps:
(1) Add ASSERT_BUG() macro definition
(2) Add SPL_ASSERT_BUG() macro definition
This version is based on 6.13-rc7, tested on x86 and LoongArch.
Tiezhu Yang (3):
drm/amd/display: Add ASSERT_BUG() macro
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/os_types.h | 5 +
1 file changed, 5
undefined behavior, so use the new added ASSERT_BUG()
and SPL_ASSERT_BUG() to stop the control flow if the divisior is zero.
Suggested-by: Nathan Chancellor
Suggested-by: Xi Ruoyao
Suggested-by: Rui Wang
Signed-off-by: Tiezhu Yang
Link: https://lore.kernel.org/lkml/20241220223403.GA2605890@ax162
On 01/11/2025 05:45 AM, Harry Wentland wrote:
On 2025-01-06 03:57, Tiezhu Yang wrote:
As far as I can tell, with the current existing macro definitions, there
is no better way to do the minimal and proper changes to stop the control
flow if the divisior is zero.
In order to keep the current
Hi Josh and Peter,
On 12/17/2024 09:08 AM, Tiezhu Yang wrote:
This version is based on tip/tip.git objtool/core branch [1], add some weak
and arch-specific functions to make the generic code more readable, tested
with the latest upstream mainline Binutils, GCC and Clang.
...
[1]
https
use the new added ASSERT_BUG()
and SPL_ASSERT_BUG() to stop the control flow if the divisior is zero.
Suggested-by: Nathan Chancellor
Suggested-by: Xi Ruoyao
Suggested-by: Rui Wang
Signed-off-by: Tiezhu Yang
Link: https://lore.kernel.org/lkml/20241220223403.GA2605890@ax162/
---
drivers/gpu/drm
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add SPL_ASSERT_BUG() macro definition
to harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/spl/spl_debug.h | 9 +
1 file
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/os_types.h | 5 +
1 file changed, 5
, tested on x86 and LoongArch.
Tiezhu Yang (5):
drm/amd/display: Replace ASSERT() with ASSERT_WARN()
drm/amd/display: Replace SPL_ASSERT() with SPL_ASSERT_WARN()
drm/amd/display: Add ASSERT_BUG() macro definition
drm/amd/display: Add SPL_ASSERT_BUG() macro definition
drm/amd/display: Harden
uot; `grep SPL_ASSERT -rwl
drivers/gpu/drm/amd/display`
This is in preparation to add SPL_ASSERT_BUG() in later patch to harden
the callers of division functions, no functional change intended.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/spl/dc_spl.c | 12 +++
.../gpu/drm/amd/
avior.
Keep the current ASSERT for the aim of debugging, just add BUG() to
stop control flow if the divisior is zero.
Suggested-by: Nathan Chancellor
Suggested-by: Xi Ruoyao
Suggested-by: Rui Wang
Signed-off-by: Tiezhu Yang
Link: https://lore.kernel.org/lkml/20241220223403.GA2605890@ax162/
---
dr
On 12/24/2024 05:46 AM, Nathan Chancellor wrote:
On Sun, Dec 22, 2024 at 12:27:47PM +0800, Tiezhu Yang wrote:
...
With the above changes, there is no "falls through" objtool warning
compiled with both clang 19 and the latest mainline clang 20.
I am somewhat surprised that change
On 12/21/2024 03:40 PM, Xi Ruoyao wrote:
On Fri, 2024-12-20 at 15:34 -0700, Nathan Chancellor wrote:
Now, the thing is, these ASSERT()s are checking for divide-by-zero, I
suspect clang figured that out and invokes UB on us and just stops
code-gen.
Yeah, I think your analysis is spot on, as thi
On 12/19/2024 03:22 AM, Alex Deucher wrote:
On Wed, Dec 18, 2024 at 2:18 PM Josh Poimboeuf wrote:
On Wed, Dec 18, 2024 at 10:36:00PM +0800, Huacai Chen wrote:
Hi, Tiezhu,
On Tue, Dec 17, 2024 at 9:50 AM Tiezhu Yang wrote:
When compiling with Clang on LoongArch, there exists the following
get a "break BRK_BUG"
trap (with unreachable annotation).
Signed-off-by: Tiezhu Yang
---
arch/loongarch/kernel/machine_kexec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/loongarch/kernel/machine_kexec.c
b/arch/loongarch/kernel/machine_kexec.c
index 8a
git/log/?h=objtool/core
Tiezhu Yang (9):
objtool: Handle various symbol types of rodata
objtool: Handle different entry size of rodata
objtool: Handle PC relative relocation type
objtool: Handle unreachable entry of rodata
objtool/LoongArch: Add support for switch table
objtool/LoongArch: A
For now, it is time to remove -fno-jump-tables to enable jump table for
objtool if the compiler has -mannotate-tablejump, otherwise it is better
to remain -fno-jump-tables to keep compatibility with older compilers.
Signed-off-by: Tiezhu Yang
---
arch/loongarch/Kconfig | 3 +++
arch/loongarch
itecture that
has different requirements.
Link: https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc
Signed-off-by: Tiezhu Yang
---
tools/objtool/arch/loongarch/decode.c | 17 +
tools/objtool/arch/loongarch/include/arch/elf.h | 7 +++
tools/objtool/check.
avoid getting the wrong jump destination
instructions.
Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0ee028f55640
Link: https://github.com/llvm/llvm-project/commit/4c2c17756739
Signed-off-by: Tiezhu Yang
---
tools/objtool/arch/loongarch/special.c | 131 -
1 file c
LoongArch.
Signed-off-by: Tiezhu Yang
---
tools/objtool/arch/loongarch/decode.c | 11 +++
tools/objtool/arch/powerpc/decode.c | 15 +++
tools/objtool/arch/x86/decode.c | 13 +
tools/objtool/check.c | 2 +-
tools/objtool/include/objtool/arch.h
: Tiezhu Yang
---
tools/objtool/check.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index cff7416b207e..654cffcf9512 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1986,9 +1986,10 @@ static int
ot;reloc->sym->offset + reloc_addend(reloc)" to obtain the symbol
offset for various symbol types.
Signed-off-by: Tiezhu Yang
---
tools/objtool/check.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index e
dc_fixpt_from_fraction() is not a simple function, just
mark it noinline to avoid the above issue.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c
ablejump_annotate", then
objtool may find the relocation info of goto table ".rodata..c_jump_table"
with find_reloc_of_rodata_c_jump_table().
Signed-off-by: Tiezhu Yang
---
tools/objtool/arch/loongarch/special.c | 32 --
1 file changed, 30 insertions(+), 2 deletion
On 09/09/2020 12:21 PM, Huacai Chen wrote:
Though RADEON_GEM_GTT_WC is initially used for GTT, but this flag is
bound to drm_arch_can_wc_memory(), and if arch doesn't support WC, then
VRAM should not use WC.
+cc RADEON and AMDGPU DRM DRIVERS maintainer
Alex Deucher
Christian König
amd-gfx@lis
On 08/09/2020 08:13 PM, Christian König wrote:
Am 08.08.20 um 15:50 schrieb Jiaxun Yang:
在 2020/8/8 下午9:41, Thomas Bogendoerfer 写道:
On Sat, Aug 08, 2020 at 03:25:02PM +0800, Tiezhu Yang wrote:
Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used
p (current fence id
0x0112 last fence id 0x011d on ring 0)
[ 60.976525] radeon :03:00.0: ring 3 stalled for more than 10086msec
[ 60.983156] radeon :03:00.0: GPU lockup (current fence id
0x0374 last fence id 0x03a8 on ring 3)
Signed-off-
On 07/02/2020 04:27 PM, Christian König wrote:
Am 02.07.20 um 04:27 schrieb Tiezhu Yang:
When I update the latest kernel, I see the following "ptrval"
boot
messages.
[1.872600] radeon :01:05.0: fence driver on ring 0 use gpu
addr 0x48000c00 and c
On 07/02/2020 04:39 PM, Christian König wrote:
Am 02.07.20 um 10:35 schrieb Tiezhu Yang:
On 07/02/2020 04:27 PM, Christian König wrote:
Am 02.07.20 um 04:27 schrieb Tiezhu Yang:
When I update the latest kernel, I see the following
"ptrval" boot
messages.
[1.872600] r
o about
CPU address.
Signed-off-by: Tiezhu Yang
---
v2:
- Just remove the debug info about CPU address suggested by Christian
- Modify the patch subject and update the commit message
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 5 ++---
drivers/gpu/drm/radeon/radeon_fence.c | 4 ++--
)
have this similar issue, fix them.
[1.872600] radeon :01:05.0: fence driver on ring 0 use gpu addr
0x48000c00 and cpu addr 0x(ptrval)
[1.879095] radeon :01:05.0: fence driver on ring 5 use gpu addr
0x40056038 and cpu addr 0x(____ptrval____)
Signed-off-by:
On 06/30/2020 04:05 PM, Christian König wrote:
Am 30.06.20 um 09:36 schrieb Tiezhu Yang:
When I update the latest kernel, I see the following "ptrval"
boot
messages. Use "%pK" instead of "%p" so that the cpu address can be
printed
when the kptr_rest
39 matches
Mail list logo
