Re: [PATCH v11 3/4] arm64: topology: Support SMT control on ACPI based system
On 3/3/25 15:40, Yicong Yang wrote:
On 2025/3/3 19:16, Sudeep Holla wrote:
On Mon, Mar 03, 2025 at 10:56:12AM +0100, Pierre Gondois wrote:
On 2/28/25 20:06, Sudeep Holla wrote:
Ditto as previous patch, can get rid if it is default 1.
On non-SMT platforms, not calling cpu_smt_set_num_threads() leaves
cpu_smt_num_threads uninitialized to UINT_MAX:
smt/active:0
smt/control:-1
If cpu_smt_set_num_threads() is called:
active:0
control:notsupported
So it might be slightly better to still initialize max_smt_thread_num.
Sure, what I meant is to have max_smt_thread_num set to 1 by default is
that is what needed anyways and the above code does that now.
Why not start with initialised to 1 instead ?
Of course some current logic needs to change around testing it for zero.
I think there would still be a way to check against the default value.
If we have:
unsigned int max_smt_thread_num = 1;
then on a platform with 2 threads, the detection condition would trigger:
xa_for_each(&hetero_cpu, hetero_id, entry) {
if (entry->thread_num != max_smt_thread_num && max_smt_thread_num) <
(entry->thread_num=2) and (max_smt_thread_num=1)
pr_warn_once("Heterogeneous SMT topology is partly
supported by SMT control\n");
so we would need an additional variable:
bool is_initialized = false;
Sure, we could do that or skip the check if max_smt_thread_num == 1 ?
I mean
if (entry->thread_num != max_smt_thread_num && max_smt_thread_num != 1)
I think it will be problematic if we parse:
- first a CPU with 1 thread
- then a CPU with 2 threads
in that case we should detect the 'Heterogeneous SMT topology',
but we cannot because we don't know whether max_smt_thread_num=1
because 1 is the default value or we found a CPU with one thread.
Re: Build Warnings at arch/powerpc/
Hello Maddy, Git bisect is poinitng to d543c29a68989ac9e39e0b50cfe8b592d92a1599 as the first bad commit. Git Bisect log: [root@ltc-zzci-1 linux-next]# git bisect log git bisect start # status: waiting for both good and bad commits # good: [7eb172143d5508b4da468ed59ee857c6e5e01da6] Linux 6.14-rc5 git bisect good 7eb172143d5508b4da468ed59ee857c6e5e01da6 # status: waiting for bad commit, 1 good commit known # bad: [cd3215bbcb9d4321def93fea6cfad4d5b42b9d1d] Add linux-next specific files for 20250303 git bisect bad cd3215bbcb9d4321def93fea6cfad4d5b42b9d1d # bad: [f084774e60dd4171a536e7f5506f90031e3a8c6f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git git bisect bad f084774e60dd4171a536e7f5506f90031e3a8c6f # good: [a57419b6b3df381d61367a3034910d1d8a197fd7] Merge branch 'fs-next' of linux-next git bisect good a57419b6b3df381d61367a3034910d1d8a197fd7 # good: [4350f3677257b7762a89901f81bc2e5ef84bc30f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git git bisect good 4350f3677257b7762a89901f81bc2e5ef84bc30f # good: [e87700965abeddcdb84c9540107c69ce08b87431] Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next git bisect good e87700965abeddcdb84c9540107c69ce08b87431 # bad: [0edfdc95d3459a6a9e9487a748b04c5b8fd2a69a] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git git bisect bad 0edfdc95d3459a6a9e9487a748b04c5b8fd2a69a # good: [97fc6863637630cdf9a5e9ed2569fe9a7974434b] net: usb: cdc_mbim: fix Telit Cinterion FE990A name git bisect good 97fc6863637630cdf9a5e9ed2569fe9a7974434b # good: [bb7abf3049025f7e4ad91cff2d9fe8381a9278af] bpf: make state->dfs_depth < state->loop_entry->dfs_depth an invariant git bisect good bb7abf3049025f7e4ad91cff2d9fe8381a9278af # good: [0ba0ef012eba63652a50b318a7a3136963c37f74] selftests/bpf: Test bpf_usdt_arg_size() function git bisect good 0ba0ef012eba63652a50b318a7a3136963c37f74 # good: [42c5e6d2accf31bba4cd31f8a742d5b9e19a7d28] selftests/bpf: Add selftests allowing cgroup prog pre-ordering git bisect good 42c5e6d2accf31bba4cd31f8a742d5b9e19a7d28 # good: [b70c222ea9d66d51fc1f038f82e41ea17b38499f] Merge branch 'bpf-next/master' into for-next git bisect good b70c222ea9d66d51fc1f038f82e41ea17b38499f # good: [cc18f482e8b60a2bcf2d7d57b48740bd0837fc04] xfrm: provide common xdo_dev_offload_ok callback implementation git bisect good cc18f482e8b60a2bcf2d7d57b48740bd0837fc04 # bad: [d543c29a68989ac9e39e0b50cfe8b592d92a1599] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git git bisect bad d543c29a68989ac9e39e0b50cfe8b592d92a1599 # good: [3ab37b090d1c458553a5268c7aaa8790ee759674] Merge branch 'main' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git git bisect good 3ab37b090d1c458553a5268c7aaa8790ee759674 # first bad commit: [d543c29a68989ac9e39e0b50cfe8b592d92a1599] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git On 04/03/25 11:43 am, Madhavan Srinivasan wrote: On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote: Greetings!! Observing build warnings with linux-next and powerpc repo's. Issue is currently not seen on mainline yet. PPC Repo: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1 next Repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch next Kernel Version: 6.14.0-rc5-next-20250303 On linux-next kernel issue got introduced b/w next-20250227 and next-20250303 Build Warnings: arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84: intra_function_call not a direct call arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated intra-function call arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call not a direct call Can you please specific the compiler and compiler version you found this issue with maddy GCC Version: gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3) If you fix this issue, please add below tag. Reported-By: Venkat Rao Bagalkote Regards, Venkat. Regards, Venkat.
Re: Build Warnings at arch/powerpc/
Le 04/03/2025 à 13:38, Madhavan Srinivasan a écrit :
On 3/4/25 4:58 PM, Madhavan Srinivasan wrote:
On 3/4/25 2:26 PM, Christophe Leroy wrote:
Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit :
On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote:
Greetings!!
Observing build warnings with linux-next and powerpc repo's. Issue is currently
not seen on mainline yet.
PPC Repo:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C48de41657f8341b927e708dd5b198b84%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766887458137690%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P9JQJ7joMFHGDws1H0iaxpj6blYAqsh4ATzrmB1A8Yc%3D&reserved=0
merge branch
PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1
next Repo:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C48de41657f8341b927e708dd5b198b84%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766887458152652%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZVQdCx62Z3ekoXOrWoE6SdHv4RvgjDFSE9CHPPJ%2FiyI%3D&reserved=0
master branch
next Kernel Version: 6.14.0-rc5-next-20250303
On linux-next kernel issue got introduced b/w next-20250227 and next-20250303
Build Warnings:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
intra_function_call not a direct call
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated
intra-function call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call
not a direct call
Can you please specific the compiler and compiler version you found this issue
with
Can you also tell which defconfig you are using or provide your .config
It might also be helpfull if you can provide a disassembly of the three file.o
around the warned address.
I could recreate the issue with gcc 11.4.1 20231218 with today's linux-next
(but could not recreate with gcc 14 or gcc 11.3.0)
(20d5c66e1810 (HEAD -> master, tag: next-20250304, origin/master, origin/HEAD)
Add linux-next specific files for 20250304)
warning for one of the switch.S file :
CC arch/powerpc/kernel/syscalls.o
AS arch/powerpc/kernel/switch.o
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call
not a direct call
I guess this is becos, for bl .+4, we recently added in the
arch_decode_instruction (decode.c) to set the type as INSN_OTHER
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
typ = INSN_OTHER;
Which I think is the issue here, changing it to INSN_CALL from INSN_OTHER fixes
the warning
Yes indeed I ended up with the same conclusion. However if you change it
back to INSN_CALL you just bring back the issue with clang using bl .+4
for relocatable code.
The warning is from here:
static int __annotate_ifc(struct objtool_file *file, int type, struct
instruction *insn)
{
unsigned long dest_off;
if (type != ANNOTYPE_INTRA_FUNCTION_CALL)
return 0;
if (insn->type != INSN_CALL) {
WARN_INSN(insn, "intra_function_call not a direct call");
return -1;
}
Now that arch_decode_instruction() does not consider bl .+4 an INSN_CALL
anymore, we have to remove the ANNOTATE_INTRA_FUNCTION_CALL annotations
here:
arch/powerpc/kernel/switch.S:42:ANNOTATE_INTRA_FUNCTION_CALL
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1527: ANNOTATE_INTRA_FUNCTION_CALL
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1534: ANNOTATE_INTRA_FUNCTION_CALL
The one in arch/powerpc/kexec/relocate_32.S is not a problem at the
moment but it looks buggy and that "bl 1f" should be replaced by a
branch to the "bcl 20,31,$+4"
I will try to cook a couple patches for all that.
The last one from the report is:
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c:
unannotated intra-function call
That one is different, we need to reproduce it to understand what it is.
Christophe
diff --git a/tools/objtool/arch/powerpc/decode.c
b/tools/objtool/arch/powerpc/decode.c
index 26d5050424a9..ffd63a61a585 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -56,7 +56,7 @@ int arch_decode_instruction(struct objtool_file *file, const
struct section *sec
switch (opcode) {
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
- typ = INSN_OTHER;
+ typ = INSN_CALL;
else if (ins & 1) /
[PATCH 1/2] tools/perf: Add field to annotation options to determine disassembler used
When doing "perf annotate", perf tool provides option to
use specific disassembler like llvm/objdump/capstone. The
order picked is to use llvm first and if that fails fallback
to objdump ie to use PERF_DISASM_LLVM, PERF_DISASM_CAPSTONE
and PERF_DISASM_OBJDUMP
In powerpc, when using "data type" sort keys, first preferred
approach is to read the raw instruction from the DSO. In objdump
is specified in "--objdump" option, it picks the symbol disassemble
using objdump. Currently disasm_line__parse_powerpc() function
uses length of the "line" to determine if objdump is used.
But there are few cases, where if objdump doesn't recognise the
instruction, the disassembled string will be empty.
Example:
134cdc:c4 05 82 41 beq 1352a0
134ce0:ac 00 8e 40 bne cr3,134d8c
134ce4:0f 00 10 04 pld r9,1028308
>134ce8:d4 b0 20 e5
134cec:16 00 40 39 li r10,22
134cf0:48 01 21 ea ld r17,328(r1)
So depending on length of line will give bad results.
Add a new filed to annotation options structure,
"struct annotation_options" to save the disassembler used.
Use this info to determine if disassembly is done while
parsing the disasm line.
Reported-by: Tejas Manhas
Signed-off-by: Athira Rajeev
---
tools/perf/util/annotate.h | 1 +
tools/perf/util/disasm.c | 22 +-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 98db1b88daf4..30a344afd91a 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -58,6 +58,7 @@ struct annotation_options {
full_addr;
u8 offset_level;
u8 disassemblers[MAX_DISASSEMBLERS];
+ u8 disassembler_used;
int min_pcnt;
int max_lines;
int context;
diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c
index 50c5c206b70e..a53e8c4e5bca 100644
--- a/tools/perf/util/disasm.c
+++ b/tools/perf/util/disasm.c
@@ -48,7 +48,7 @@ static int call__scnprintf(struct ins *ins, char *bf, size_t
size,
static void ins__sort(struct arch *arch);
static int disasm_line__parse(char *line, const char **namep, char **rawp);
-static int disasm_line__parse_powerpc(struct disasm_line *dl);
+static int disasm_line__parse_powerpc(struct disasm_line *dl, struct
annotate_args *args);
static char *expand_tabs(char *line, char **storage, size_t *storage_len);
static __attribute__((constructor)) void symbol__init_regexpr(void)
@@ -968,24 +968,24 @@ static int disasm_line__parse(char *line, const char
**namep, char **rawp)
#definePPC_OP(op) (((op) >> 26) & 0x3F)
#defineRAW_BYTES 11
-static int disasm_line__parse_powerpc(struct disasm_line *dl)
+static int disasm_line__parse_powerpc(struct disasm_line *dl, struct
annotate_args *args)
{
char *line = dl->al.line;
const char **namep = &dl->ins.name;
char **rawp = &dl->ops.raw;
char *tmp_raw_insn, *name_raw_insn = skip_spaces(line);
char *name = skip_spaces(name_raw_insn + RAW_BYTES);
- int objdump = 0;
+ int disasm = 0;
- if (strlen(line) > RAW_BYTES)
- objdump = 1;
+ if (args->options->disassembler_used)
+ disasm = 1;
if (name_raw_insn[0] == '\0')
return -1;
- if (objdump) {
+ if (disasm)
disasm_line__parse(name, namep, rawp);
- } else
+ else
*namep = "";
tmp_raw_insn = strndup(name_raw_insn, 11);
@@ -995,7 +995,7 @@ static int disasm_line__parse_powerpc(struct disasm_line
*dl)
remove_spaces(tmp_raw_insn);
sscanf(tmp_raw_insn, "%x", &dl->raw.raw_insn);
- if (objdump)
+ if (disasm)
dl->raw.raw_insn = be32_to_cpu(dl->raw.raw_insn);
return 0;
@@ -1054,7 +1054,7 @@ struct disasm_line *disasm_line__new(struct annotate_args
*args)
if (args->offset != -1) {
if (arch__is(args->arch, "powerpc")) {
- if (disasm_line__parse_powerpc(dl) < 0)
+ if (disasm_line__parse_powerpc(dl, args) < 0)
goto out_free_line;
} else if (disasm_line__parse(dl->al.line, &dl->ins.name,
&dl->ops.raw) < 0)
goto out_free_line;
@@ -2289,16 +2289,20 @@ int symbol__disassemble(struct symbol *sym, struct
annotate_args *args)
switch (dis) {
case PERF_DISASM_LLVM:
+ args->options->disassembler_used = PERF_DISASM_LLVM;
err = symbol__disassemble_llvm(symfs_filename, sym,
args);
break;
case PERF_DISASM_CAPSTONE:
+ args->options->disassembler_used = PERF_DISASM_CAPSTONE;
err = symbol__disassemble_capstone(symfs_filename, sym,
args);
break;
[PATCH 2/2] tools/perf/powerpc: Use return code from disasm_line__parse
In disasm_line__parse_powerpc() , return code from function disasm_line__parse() is ignored. This will result in bad results if the disasm_line__parse fails to disasm the line. Use the return code to fix this. Signed-off-by: Athira Rajeev --- tools/perf/util/disasm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c index a53e8c4e5bca..8f0eb56c6fc6 100644 --- a/tools/perf/util/disasm.c +++ b/tools/perf/util/disasm.c @@ -976,6 +976,7 @@ static int disasm_line__parse_powerpc(struct disasm_line *dl, struct annotate_ar char *tmp_raw_insn, *name_raw_insn = skip_spaces(line); char *name = skip_spaces(name_raw_insn + RAW_BYTES); int disasm = 0; + int ret = 0; if (args->options->disassembler_used) disasm = 1; @@ -984,7 +985,7 @@ static int disasm_line__parse_powerpc(struct disasm_line *dl, struct annotate_ar return -1; if (disasm) - disasm_line__parse(name, namep, rawp); + ret = disasm_line__parse(name, namep, rawp); else *namep = ""; @@ -998,7 +999,7 @@ static int disasm_line__parse_powerpc(struct disasm_line *dl, struct annotate_ar if (disasm) dl->raw.raw_insn = be32_to_cpu(dl->raw.raw_insn); - return 0; + return ret; } static void annotation_line__init(struct annotation_line *al, -- 2.43.5
Re: [PATCH v11 3/4] arm64: topology: Support SMT control on ACPI based system
On 3/4/25 11:02, Sudeep Holla wrote:
On Tue, Mar 04, 2025 at 09:25:02AM +0100, Pierre Gondois wrote:
On 3/3/25 15:40, Yicong Yang wrote:
On 2025/3/3 19:16, Sudeep Holla wrote:
On Mon, Mar 03, 2025 at 10:56:12AM +0100, Pierre Gondois wrote:
On 2/28/25 20:06, Sudeep Holla wrote:
Ditto as previous patch, can get rid if it is default 1.
On non-SMT platforms, not calling cpu_smt_set_num_threads() leaves
cpu_smt_num_threads uninitialized to UINT_MAX:
smt/active:0
smt/control:-1
If cpu_smt_set_num_threads() is called:
active:0
control:notsupported
So it might be slightly better to still initialize max_smt_thread_num.
Sure, what I meant is to have max_smt_thread_num set to 1 by default is
that is what needed anyways and the above code does that now.
Why not start with initialised to 1 instead ?
Of course some current logic needs to change around testing it for zero.
I think there would still be a way to check against the default value.
If we have:
unsigned int max_smt_thread_num = 1;
then on a platform with 2 threads, the detection condition would trigger:
xa_for_each(&hetero_cpu, hetero_id, entry) {
if (entry->thread_num != max_smt_thread_num && max_smt_thread_num) <
(entry->thread_num=2) and (max_smt_thread_num=1)
pr_warn_once("Heterogeneous SMT topology is partly
supported by SMT control\n");
so we would need an additional variable:
bool is_initialized = false;
Sure, we could do that or skip the check if max_smt_thread_num == 1 ?
I mean
if (entry->thread_num != max_smt_thread_num && max_smt_thread_num != 1)
I think it will be problematic if we parse:
- first a CPU with 1 thread
- then a CPU with 2 threads
in that case we should detect the 'Heterogeneous SMT topology',
but we cannot because we don't know whether max_smt_thread_num=1
because 1 is the default value or we found a CPU with one thread.
Right, but as per Dietmar's and my previous response, it may be a valid
case. See latest response from Dietmar which is explicitly requesting
support for this. It may need some special handling if we decide to support
that.
Ah ok, right indeed.
For heterogeneous SMT platforms, the 'smt/control' file is able to accept
on/off/forceoff strings. But providing the max #count of threads as an integer
would
be wrong if the CPU doesn't have this #count of threads.
Initially the idea was to just warn that support might be needed for
heterogeneous
SMT platforms, and let whoever would have such platform solve this case, but
just
disabling the integer interface in this case would solve the issue generically.
Re: Build Warnings at arch/powerpc/
On 3/4/25 4:58 PM, Madhavan Srinivasan wrote:
>
>
> On 3/4/25 2:26 PM, Christophe Leroy wrote:
>>
>>
>> Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit :
>>>
>>>
>>> On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote:
>>>> Greetings!!
>>>>
>>>>
>>>> Observing build warnings with linux-next and powerpc repo's. Issue is
>>>> currently not seen on mainline yet.
>>>>
>>>> PPC Repo:
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585342184%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e5BrJzcrtlITkLF31KltGExQ5Qe8fDVTMV6VfR4w9o8%3D&reserved=0
>>>> merge branch
>>>>
>>>> PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1
>>>> next Repo:
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585355246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=meQyZfB75HhJFCL6AX93slsyVwnogGPYFabDXl%2FLzDA%3D&reserved=0
>>>> master branch
>>>>
>>>> next Kernel Version: 6.14.0-rc5-next-20250303
>>>>
>>>>
>>>> On linux-next kernel issue got introduced b/w next-20250227 and
>>>> next-20250303
>>>>
>>>>
>>>> Build Warnings:
>>>>
>>>> arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
>>>> intra_function_call not a direct call
>>>> arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c:
>>>> unannotated intra-function call
>>>> arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
>>>> intra_function_call not a direct call
>>>>
>>>>
>>>
>>> Can you please specific the compiler and compiler version you found this
>>> issue with
>>>
>>
>> Can you also tell which defconfig you are using or provide your .config
>>
>> It might also be helpfull if you can provide a disassembly of the three
>> file.o around the warned address.
>
> I could recreate the issue with gcc 11.4.1 20231218 with today's linux-next
> (but could not recreate with gcc 14 or gcc 11.3.0)
>
> (20d5c66e1810 (HEAD -> master, tag: next-20250304, origin/master,
> origin/HEAD) Add linux-next specific files for 20250304)
>
> warning for one of the switch.S file :
>
> CC arch/powerpc/kernel/syscalls.o
> AS arch/powerpc/kernel/switch.o
> arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
> intra_function_call not a direct call
I guess this is becos, for bl .+4, we recently added in the
arch_decode_instruction (decode.c) to set the type as INSN_OTHER
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
typ = INSN_OTHER;
Which I think is the issue here, changing it to INSN_CALL from INSN_OTHER fixes
the warning
diff --git a/tools/objtool/arch/powerpc/decode.c
b/tools/objtool/arch/powerpc/decode.c
index 26d5050424a9..ffd63a61a585 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -56,7 +56,7 @@ int arch_decode_instruction(struct objtool_file *file, const
struct section *sec
switch (opcode) {
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
- typ = INSN_OTHER;
+ typ = INSN_CALL;
else if (ins & 1) /* bl[a] */
typ = INSN_CALL;
else/* b[a] */
Maddy
> CC arch/powerpc/kernel/irq.o
> CC arch/powerpc/kernel/align.o
> CC arch/powerpc/kernel/signal_64.o
>
> Objdump of switch.o:
> arch/powerpc/kernel/switch.o: file format elf64-powerpcle
>
> Disassembly of section .text:
>
> :
>0: a6 02 28 7d mflrr9
>4: 05 00 00 48 bl 8
>8: 05 00 00 48 bl c
>c: 05 00 00 48 bl 10
> 10: 05 00 00 48 bl 14
> 14: 05 00 00 48 bl 18
> 18: 05 00 00 48 bl 1c
> 1c: 05 00 00 48 bl 20
> 20: 05 00 00 48 bl 24
> 24: 05 00 00 48 bl 28
> 28: 05 00 00 48 bl 2c
>
>
> arch/powerpc/kernel/switch.S failing src section:
>
> .balign 32
> .global flush_branch_caches
> flush_branch_caches:
> /* Save LR into r9 */
> mflrr9
>
> // Flush the link stack
> .rept 64
> ANNOTATE_INTRA_FUNCTION_CALL
> bl .+4
> .endr
> b 1f
> nops6
>
> Maddy
>
>
>>
>> Christophe
>
>
Re: Build Warnings at arch/powerpc/
Le 04/03/2025 à 14:03, Venkat Rao Bagalkote a écrit :
[Vous ne recevez pas souvent de courriers de venka...@linux.ibm.com.
Découvrez pourquoi ceci est important à https://aka.ms/
LearnAboutSenderIdentification ]
On 04/03/25 6:08 pm, Madhavan Srinivasan wrote:
On 3/4/25 4:58 PM, Madhavan Srinivasan wrote:
On 3/4/25 2:26 PM, Christophe Leroy wrote:
Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit :
On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote:
Greetings!!
Observing build warnings with linux-next and powerpc repo's. Issue
is currently not seen on mainline yet.
PPC Repo: https://eur01.safelinks.protection.outlook.com/?
url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C6e17cc771a204b2998b508dd5b1cf2cf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766902127463526%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f0ubC0BiY%2Fw2XLfXcX955JKhJ%2BRkUmTUVO4fV%2F%2F4v2Y%3D&reserved=0 merge branch
PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1
next Repo: https://eur01.safelinks.protection.outlook.com/?
url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C6e17cc771a204b2998b508dd5b1cf2cf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766902127477000%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GSDtRBQ35owCeEpjMMCNiJw3iizdrUPQcHznop2BLeQ%3D&reserved=0 master branch
next Kernel Version: 6.14.0-rc5-next-20250303
On linux-next kernel issue got introduced b/w next-20250227 and
next-20250303
Build Warnings:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning:
objtool: .text+0xe84: intra_function_call not a direct call
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c:
unannotated intra-function call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
Can you please specific the compiler and compiler version you found
this issue with
Can you also tell which defconfig you are using or provide your .config
It might also be helpfull if you can provide a disassembly of the
three file.o around the warned address.
I could recreate the issue with gcc 11.4.1 20231218 with today's
linux-next (but could not recreate with gcc 14 or gcc 11.3.0)
(20d5c66e1810 (HEAD -> master, tag: next-20250304, origin/master,
origin/HEAD) Add linux-next specific files for 20250304)
warning for one of the switch.S file :
CC arch/powerpc/kernel/syscalls.o
AS arch/powerpc/kernel/switch.o
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
I guess this is becos, for bl .+4, we recently added in the
arch_decode_instruction (decode.c) to set the type as INSN_OTHER
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
typ = INSN_OTHER;
Which I think is the issue here, changing it to INSN_CALL from
INSN_OTHER fixes the warning
diff --git a/tools/objtool/arch/powerpc/decode.c b/tools/objtool/arch/
powerpc/decode.c
index 26d5050424a9..ffd63a61a585 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -56,7 +56,7 @@ int arch_decode_instruction(struct objtool_file
*file, const struct section *sec
switch (opcode) {
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
- typ = INSN_OTHER;
+ typ = INSN_CALL;
else if (ins & 1) /* bl[a] */
typ = INSN_CALL;
else /* b[a] */
Maddy
Maddy,
I changed the code manually and gave it a try. The Proposed fix,
partially fixes the issue. It gets rid of two of the warnings, but below
warning still persists.
It fixes the issue for you but will reintroduce the issue with clang.
The real fix is to remove the ANNOTATE_INTRA_FUNCTION_CALL in:
arch/powerpc/kernel/switch.S:42:ANNOTATE_INTRA_FUNCTION_CALL
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1527: ANNOTATE_INTRA_FUNCTION_CALL
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1534: ANNOTATE_INTRA_FUNCTION_CALL
Can you give it a try ?
For the last one, can you provide an assembly dump ? You get it with
"objtool -dr arch/powerpc/crypto/ghashp8-ppc.o"
Also can you tell which defconfig you use or provide your .config if not
standard one ?
Christophe
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c:
unannotated intra-function call
CC arch/powerpc/kernel/irq.o
CC arch/powerpc/kernel/align.o
CC arch/powerpc/kernel/signal_64.o
Objdump of switch.o:
arch/powerpc/kernel/switch.o: file f
Re: Build Warnings at arch/powerpc/
On 04/03/25 6:08 pm, Madhavan Srinivasan wrote:
On 3/4/25 4:58 PM, Madhavan Srinivasan wrote:
On 3/4/25 2:26 PM, Christophe Leroy wrote:
Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit :
On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote:
Greetings!!
Observing build warnings with linux-next and powerpc repo's. Issue is currently
not seen on mainline yet.
PPC Repo:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585342184%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e5BrJzcrtlITkLF31KltGExQ5Qe8fDVTMV6VfR4w9o8%3D&reserved=0
merge branch
PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1
next Repo:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585355246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=meQyZfB75HhJFCL6AX93slsyVwnogGPYFabDXl%2FLzDA%3D&reserved=0
master branch
next Kernel Version: 6.14.0-rc5-next-20250303
On linux-next kernel issue got introduced b/w next-20250227 and next-20250303
Build Warnings:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
intra_function_call not a direct call
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated
intra-function call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call
not a direct call
Can you please specific the compiler and compiler version you found this issue
with
Can you also tell which defconfig you are using or provide your .config
It might also be helpfull if you can provide a disassembly of the three file.o
around the warned address.
I could recreate the issue with gcc 11.4.1 20231218 with today's linux-next
(but could not recreate with gcc 14 or gcc 11.3.0)
(20d5c66e1810 (HEAD -> master, tag: next-20250304, origin/master, origin/HEAD)
Add linux-next specific files for 20250304)
warning for one of the switch.S file :
CC arch/powerpc/kernel/syscalls.o
AS arch/powerpc/kernel/switch.o
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call
not a direct call
I guess this is becos, for bl .+4, we recently added in the
arch_decode_instruction (decode.c) to set the type as INSN_OTHER
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
typ = INSN_OTHER;
Which I think is the issue here, changing it to INSN_CALL from INSN_OTHER fixes
the warning
diff --git a/tools/objtool/arch/powerpc/decode.c
b/tools/objtool/arch/powerpc/decode.c
index 26d5050424a9..ffd63a61a585 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -56,7 +56,7 @@ int arch_decode_instruction(struct objtool_file *file, const
struct section *sec
switch (opcode) {
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
- typ = INSN_OTHER;
+ typ = INSN_CALL;
else if (ins & 1) /* bl[a] */
typ = INSN_CALL;
else/* b[a] */
Maddy
Maddy,
I changed the code manually and gave it a try. The Proposed fix,
partially fixes the issue. It gets rid of two of the warnings, but below
warning still persists.
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c:
unannotated intra-function call
CC arch/powerpc/kernel/irq.o
CC arch/powerpc/kernel/align.o
CC arch/powerpc/kernel/signal_64.o
Objdump of switch.o:
arch/powerpc/kernel/switch.o: file format elf64-powerpcle
Disassembly of section .text:
:
0: a6 02 28 7d mflrr9
4: 05 00 00 48 bl 8
8: 05 00 00 48 bl c
c: 05 00 00 48 bl 10
10: 05 00 00 48 bl 14
14: 05 00 00 48 bl 18
18: 05 00 00 48 bl 1c
1c: 05 00 00 48 bl 20
20: 05 00 00 48 bl 24
24: 05 00 00 48 bl 28
28: 05 00 00 48 bl 2c
arch/powerpc/kernel/switch.S failing src section:
.balign 32
.global flush_branch_caches
flush_branch_caches:
/* Save LR into r9 */
mflrr9
// Flush the link stack
.rept 64
ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage()
Hi,Catalin: Kindly ping ... Thanks.:) 在 2025/2/19 3:42, Catalin Marinas 写道: On Tue, Feb 18, 2025 at 07:51:10PM +0800, Tong Tiangen wrote: 在 2025/2/13 1:11, Catalin Marinas 写道: On Mon, Dec 09, 2024 at 10:42:56AM +0800, Tong Tiangen wrote: Currently, many scenarios that can tolerate memory errors when copying page have been supported in the kernel[1~5], all of which are implemented by copy_mc_[user]_highpage(). arm64 should also support this mechanism. Due to mte, arm64 needs to have its own copy_mc_[user]_highpage() architecture implementation, macros __HAVE_ARCH_COPY_MC_HIGHPAGE and __HAVE_ARCH_COPY_MC_USER_HIGHPAGE have been added to control it. Add new helper copy_mc_page() which provide a page copy implementation with hardware memory error safe. The code logic of copy_mc_page() is the same as copy_page(), the main difference is that the ldp insn of copy_mc_page() contains the fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR, therefore, the main logic is extracted to copy_page_template.S. In addition, the fixup of MOPS insn is not considered at present. Could we not add the exception table entry permanently but ignore the exception table entry if it's not on the do_sea() path? That would save some code duplication. [...] So we need another way to distinguish the different processing of the same exception type on SEA and non-SEA path. Distinguishing whether the fault is SEA or non-SEA is already done by the exception handling you are adding. What we don't have though is information about whether the caller invoked copy_highpage() or copy_mc_highpage(). That's where the code duplication comes in handy. It's a shame we need to duplicate identical functions just to have different addresses to look up in the exception table. We are also short of caller saved registers to track this information (e.g. an extra argument to those functions that the exception handler interprets). I need to think a bit more, we could in theory get the arm64 memcpy_mc() to return an error code depending on what type of fault it got (e.g. -EHWPOISON for SEA, -EFAULT for non-SEA). copy_mc_highpage() would interpret this one and panic if -EFAULT. But we lose some fault details we normally get on a faulty access like some of the registers. Well, maybe the simples is still to keep the function duplication. I'll have another look at the series tomorrow.
Re: [PATCH v3] dt-bindings: dma: Convert fsl,elo*-dma to YAML
On Mon, Mar 03, 2025 at 07:42:00AM -0600, Rob Herring wrote: > On Wed, Feb 26, 2025 at 11:29:54AM -0600, Rob Herring (Arm) wrote: > > > > On Wed, 26 Feb 2025 16:57:17 +0100, J. Neuschäfer wrote: > > > The devicetree bindings for Freescale DMA engines have so far existed as > > > a text file. This patch converts them to YAML, and specifies all the > > > compatible strings currently in use in arch/powerpc/boot/dts. > > > > > > Signed-off-by: J. Neuschäfer > > > --- [...] > > dtschema/dtc warnings/errors: > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/fsl,elo-dma.example.dtb: > > dma-controller@82a8: '#dma-cells' is a required property > > from schema $id: http://devicetree.org/schemas/dma/dma-controller.yaml# > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.example.dtb: > > dma-controller@21300: '#dma-cells' is a required property > > from schema $id: http://devicetree.org/schemas/dma/dma-controller.yaml# > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/fsl,elo3-dma.example.dtb: > > dma-controller@100300: '#dma-cells' is a required property > > from schema $id: http://devicetree.org/schemas/dma/dma-controller.yaml# > > Just stick with 'dma' for node name as that's what .dts files are using > and 'dma-controller' is reserved for users of DMA provider binding. > > Rob Ok, makes sense. Thanks, J. Neuschäfer
Re: Build Warnings at arch/powerpc/
Le 04/03/2025 à 16:44, Venkat Rao Bagalkote a écrit :
Hello Christophe,
On 04/03/25 6:43 pm, Christophe Leroy wrote:
Le 04/03/2025 à 14:03, Venkat Rao Bagalkote a écrit :
[Vous ne recevez pas souvent de courriers de venka...@linux.ibm.com.
Découvrez pourquoi ceci est important à https://
eur01.safelinks.protection.outlook.com/?
url=https%3A%2F%2Faka.ms%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C3657f07f71b149ba489e08dd5b336e9a%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766998669498918%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZM65b%2F3BuUDy5Iet3kE1%2B%2BXKdjmM86UFsJwBmSHeiv4%3D&reserved=0 LearnAboutSenderIdentification ]
On 04/03/25 6:08 pm, Madhavan Srinivasan wrote:
On 3/4/25 4:58 PM, Madhavan Srinivasan wrote:
On 3/4/25 2:26 PM, Christophe Leroy wrote:
Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit :
On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote:
Greetings!!
Observing build warnings with linux-next and powerpc repo's.
Issue is currently not seen on mainline yet.
PPC Repo: https://eur01.safelinks.protection.outlook.com/?
url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C6e17cc771a204b2998b508dd5b1cf2cf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766902127463526%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f0ubC0BiY%2Fw2XLfXcX955JKhJ%2BRkUmTUVO4fV%2F%2F4v2Y%3D&reserved=0 merge branch
PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1
next Repo: https://eur01.safelinks.protection.outlook.com/?
url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C6e17cc771a204b2998b508dd5b1cf2cf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766902127477000%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GSDtRBQ35owCeEpjMMCNiJw3iizdrUPQcHznop2BLeQ%3D&reserved=0 master branch
next Kernel Version: 6.14.0-rc5-next-20250303
On linux-next kernel issue got introduced b/w next-20250227 and
next-20250303
Build Warnings:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning:
objtool: .text+0xe84: intra_function_call not a direct call
arch/powerpc/crypto/ghashp8-ppc.o: warning:
objtool: .text+0x22c: unannotated intra-function call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
Can you please specific the compiler and compiler version you
found this issue with
Can you also tell which defconfig you are using or provide
your .config
It might also be helpfull if you can provide a disassembly of the
three file.o around the warned address.
I could recreate the issue with gcc 11.4.1 20231218 with today's
linux-next (but could not recreate with gcc 14 or gcc 11.3.0)
(20d5c66e1810 (HEAD -> master, tag: next-20250304, origin/master,
origin/HEAD) Add linux-next specific files for 20250304)
warning for one of the switch.S file :
CC arch/powerpc/kernel/syscalls.o
AS arch/powerpc/kernel/switch.o
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
I guess this is becos, for bl .+4, we recently added in the
arch_decode_instruction (decode.c) to set the type as INSN_OTHER
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
typ = INSN_OTHER;
Which I think is the issue here, changing it to INSN_CALL from
INSN_OTHER fixes the warning
diff --git a/tools/objtool/arch/powerpc/decode.c b/tools/objtool/
arch/ powerpc/decode.c
index 26d5050424a9..ffd63a61a585 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -56,7 +56,7 @@ int arch_decode_instruction(struct objtool_file
*file, const struct section *sec
switch (opcode) {
case 18: /* b[l][a] */
if (ins == 0x4805) /* bl .+4 */
- typ = INSN_OTHER;
+ typ = INSN_CALL;
else if (ins & 1) /* bl[a] */
typ = INSN_CALL;
else /* b[a] */
Maddy
Maddy,
I changed the code manually and gave it a try. The Proposed fix,
partially fixes the issue. It gets rid of two of the warnings, but below
warning still persists.
It fixes the issue for you but will reintroduce the issue with clang.
The real fix is to remove the ANNOTATE_INTRA_FUNCTION_CALL in:
arch/powerpc/kernel/switch.S:42: ANNOTATE_INTRA_FUNCTION_CALL
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1527:
ANNOTATE_INTRA_FUNCTION_CALL
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1534:
ANNOTATE_INTRA_FUNCTION_CALL
Removed ANNOTAT
Re: [PATCH v4] powerpc/hugetlb: Disable gigantic hugepages if fadump is active
Hello Ritesh,
On 04/03/25 10:27, Ritesh Harjani (IBM) wrote:
Sourabh Jain writes:
Hello Ritesh,
Thanks for the review.
On 02/03/25 12:05, Ritesh Harjani (IBM) wrote:
Sourabh Jain writes:
The fadump kernel boots with limited memory solely to collect the kernel
core dump. Having gigantic hugepages in the fadump kernel is of no use.
Sure got it.
Many times, the fadump kernel encounters OOM (Out of Memory) issues if
gigantic hugepages are allocated.
To address this, disable gigantic hugepages if fadump is active by
returning early from arch_hugetlb_valid_size() using
hugepages_supported(). When fadump is active, the global variable
hugetlb_disabled is set to true, which is later used by the
PowerPC-specific hugepages_supported() function to determine hugepage
support.
Returning early from arch_hugetlb_vali_size() not only disables
gigantic hugepages but also avoids unnecessary hstate initialization for
every hugepage size supported by the platform.
kernel logs related to hugepages with this patch included:
kernel argument passed: hugepagesz=1G hugepages=1
First kernel: gigantic hugepage got allocated
==
dmesg | grep -i "hugetlb"
-
HugeTLB: registered 1.00 GiB page size, pre-allocated 1 pages
HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
$ cat /proc/meminfo | grep -i "hugetlb"
-
Hugetlb: 1048576 kB
Was this tested with patch [1] in your local tree?
[1]:
https://web.git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=d629d7a8efc33
IIUC, this patch [1] disables the boot time allocation of hugepages.
Isn't it also disabling the boot time allocation for gigantic huge pages
passed by the cmdline params like hugepagesz=1G and hugepages=2 ?
Yes, I had the patch [1] in my tree.
My understanding is that gigantic pages are allocated before normal huge
pages.
In hugepages_setup() in hugetlb.c, we have:
if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate))
hugetlb_hstate_alloc_pages(parsed_hstate);
I believe the above code allocates memory for gigantic pages, and
hugetlb_init() is
called later because it is a subsys_initcall.
So, by the time the kernel reaches hugetlb_init(), the gigantic pages
are already
allocated. Isn't that right?
Please let me know your opinion.
Yes, you are right. We are allocating hugepages from memblock, however
this isn't getting advertized anywhere. i.e. there is no way one can
know from any user interface on whether hugepages were allocated or not.
i.e. for fadump kernel when hugepagesz= and hugepages= params are
passed, though it will allocate gigantic pages, it won't advertize this
in meminfo or anywhere else. This was adding the confusion when I tested
this (which wasn't clear from the commit msg either).
Yeah I should have added that in my commit message.
And I guess this is happening during fadump kernel because of our patch
[1], which added a check to see whether hugetlb_disabled is true in-
hugepages_supported(). Due to this hugetlb_init() is now not doing the
rest of the initialization for those gigantic pages which were allocated
due to cmdline options from hugepages_setup().
Yeah patch [1] has disabled the hugetlb initialization.
[1]:
https://lore.kernel.org/linuxppc-dev/20241202054310.928610-1-sourabhj...@linux.ibm.com/
Now as we know from below that fadump can set hugetlb_disabled call in
early_setup().
i.e. fadump can mark hugetlb_disabled to true in
early_setup() -> early_init_devtree() -> fadump_reserve_mem()
And hugepages_setup() and hugepagesz_setup() gets called late in
start_kernel() -> parse_args()
And we already check for hugepages_supported() in all necessary calls in
mm/hugetlb.c. So IMO, this check should go in mm/hugetlb.c in
hugepagesz_setup() and hugepages_setup(). Because otherwise every arch
implementation will end up duplicating this by adding
hugepages_supported() check in their arch implementation of
arch_hugetlb_valid_size().
e.g. references of hugepages_supported() checks in mm/hugetlb.c
mm/hugetlb.c hugetlb_show_meminfo_node 4959 if (!hugepages_supported())
mm/hugetlb.c hugetlb_report_node_meminfo 4943 if (!hugepages_supported())
mm/hugetlb.c hugetlb_report_meminfo 4914 if (!hugepages_supported())
mm/hugetlb.c hugetlb_overcommit_handler 4848 if (!hugepages_supported())
mm/hugetlb.c hugetlb_sysctl_handler_common 4809 if (!hugepages_supported())
mm/hugetlb.c hugetlb_init 4461 if (!hugepages_supported()) {
mm/hugetlb.c dissolve_free_hugetlb_folios 2211 if (!hugepages_supported())
fs/hugetlbfs/inode.c init_hugetlbfs_fs 1604 if (!hugepages_supported()) {
v1 proposed to do it in generic code:
https://lore.kernel.org/all/20250121150419.1342794-1-sourabhj...@linux.ibm.com/
But it was suggested to try it in arch specific code.
Let me al
Re: [PATCH] powerpc: Fix 'intra_function_call not a direct call' warning
On 3/5/25 4:30 AM, Christophe Leroy wrote:
The following build warning have been reported:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
intra_function_call not a direct call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support
for decoding all types of uncond branches") because that commit decodes
'bl .+4' as a normal instruction because that instruction is used by
clang instead of 'bcl 20,31,+.4' for relocatable code.
The solution is simply to remove the ANNOTATE_INTRA_FUNCTION_CALL
annotation now that the instruction is not seen as a function call
anymore.
Reported-by: Venkat Rao Bagalkote
Closes:https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d611...@linux.ibm.com
Fixes: bb7f054f4de2 ("objtool/powerpc: Add support for decoding all types of uncond
branches")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/switch.S| 1 -
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/switch.S b/arch/powerpc/kernel/switch.S
index 608c0ce7cec6..59e3ee99db0e 100644
--- a/arch/powerpc/kernel/switch.S
+++ b/arch/powerpc/kernel/switch.S
@@ -39,7 +39,6 @@ flush_branch_caches:
// Flush the link stack
.rept 64
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
b 1f
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index ea7ad200b330..83f7504349d2 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1524,14 +1524,12 @@ kvm_flush_link_stack:
/* Flush the link stack. On Power8 it's up to 32 entries in size. */
.rept 32
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
/* And on Power9 it's up to 64. */
BEGIN_FTR_SECTION
.rept 32
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
The warnings are now fixed and the patch looks good to me.
Reviewed-by: Sathvika Vasireddy
Thanks,
Sathvika
[PATCH] crypto: powerpc: Mark ghashp8-ppc.o as an OBJECT_FILES_NON_STANDARD
The following build warning has been reported:
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated
intra-function call
This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support
for decoding all types of uncond branches")
Disassembly of arch/powerpc/crypto/ghashp8-ppc.o shows:
arch/powerpc/crypto/ghashp8-ppc.o: file format elf64-powerpcle
Disassembly of section .text:
0140 :
140:f8 ff 00 3c lis r0,-8
...
20c:20 00 80 4e blr
210:00 00 00 00 .long 0x0
214:00 0c 14 00 .long 0x140c00
218:00 00 04 00 .long 0x4
21c:00 00 00 00 .long 0x0
220:47 48 41 53 rlwimi. r1,r26,9,1,3
224:48 20 66 6f xoris r6,r27,8264
228:72 20 50 6f xoris r16,r26,8306
22c:77 65 72 49 bla 1726574 <==
...
It corresponds to the following code in ghashp8-ppc.o :
_GLOBAL(gcm_ghash_p8)
lis0,0xfff8
...
blr
.long0
.byte0,12,0x14,0,0,0,4,0
.long0
.sizegcm_ghash_p8,.-gcm_ghash_p8
.byte
71,72,65,83,72,32,102,111,114,32,80,111,119,101,114,73,83,65,32,50,46,48,55,44,32,67,82,89,80,84,79,71,65,77,83,32,98,121,32,60,97,112,112,114,111,64,111,112,101,110,115,115,108,46,111,114,103,62,0
.align2
.align2
In fact this is raw data that is after the function end and that is
not text so shouldn't be disassembled as text. But ghashp8-ppc.S is
generated by a perl script and should have been marked as
OBJECT_FILES_NON_STANDARD.
Now that 'bla' is understood as a call instruction, that raw data
is mis-interpreted as an infra-function call.
Mark ghashp8-ppc.o as a OBJECT_FILES_NON_STANDARD to avoid this
warning.
Reported-by: Venkat Rao Bagalkote
Closes:
https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d611...@linux.ibm.com
Cc: Danny Tsen
Fixes: 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto")
Signed-off-by: Christophe Leroy
---
arch/powerpc/crypto/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/crypto/Makefile b/arch/powerpc/crypto/Makefile
index 9b38f4a7bc15..2f00b22b0823 100644
--- a/arch/powerpc/crypto/Makefile
+++ b/arch/powerpc/crypto/Makefile
@@ -51,3 +51,4 @@ $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S: $(obj)/%.S:
$(src)/%.pl FORCE
OBJECT_FILES_NON_STANDARD_aesp10-ppc.o := y
OBJECT_FILES_NON_STANDARD_ghashp10-ppc.o := y
OBJECT_FILES_NON_STANDARD_aesp8-ppc.o := y
+OBJECT_FILES_NON_STANDARD_ghashp8-ppc.o := y
--
2.47.0
[PATCH] powerpc: Fix 'intra_function_call not a direct call' warning
The following build warning have been reported:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
intra_function_call not a direct call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support
for decoding all types of uncond branches") because that commit decodes
'bl .+4' as a normal instruction because that instruction is used by
clang instead of 'bcl 20,31,+.4' for relocatable code.
The solution is simply to remove the ANNOTATE_INTRA_FUNCTION_CALL
annotation now that the instruction is not seen as a function call
anymore.
Reported-by: Venkat Rao Bagalkote
Closes:
https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d611...@linux.ibm.com
Fixes: bb7f054f4de2 ("objtool/powerpc: Add support for decoding all types of
uncond branches")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/switch.S| 1 -
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/switch.S b/arch/powerpc/kernel/switch.S
index 608c0ce7cec6..59e3ee99db0e 100644
--- a/arch/powerpc/kernel/switch.S
+++ b/arch/powerpc/kernel/switch.S
@@ -39,7 +39,6 @@ flush_branch_caches:
// Flush the link stack
.rept 64
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
b 1f
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index ea7ad200b330..83f7504349d2 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1524,14 +1524,12 @@ kvm_flush_link_stack:
/* Flush the link stack. On Power8 it's up to 32 entries in size. */
.rept 32
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
/* And on Power9 it's up to 64. */
BEGIN_FTR_SECTION
.rept 32
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
--
2.47.0
[PATCH] powerpc: Fix address calculation in clear_utlb_entry()
In relocatable.S, function clear_utlb_entry() goes into real mode. To do so, it has to calculate the physical address based on the virtual address. To get the virtual address it used 'bl' which is problematic (see commit XXX). In addition, the calculation is done on a bad address, which may lead to unexpected behaviour. Fix it by re-writing the code so that is goes via another path which is based 'bcl 20,31,.+4' which is the right instruction to use for that. Signed-off-by: Christophe Leroy --- arch/powerpc/kexec/relocate_32.S | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kexec/relocate_32.S b/arch/powerpc/kexec/relocate_32.S index 104c9911f406..dd86e338307d 100644 --- a/arch/powerpc/kexec/relocate_32.S +++ b/arch/powerpc/kexec/relocate_32.S @@ -348,16 +348,13 @@ write_utlb: rlwinm r10, r24, 0, 22, 27 cmpwi r10, PPC47x_TLB0_4K - bne 0f li r10, 0x1000 /* r10 = 4k */ - ANNOTATE_INTRA_FUNCTION_CALL - bl 1f + beq 0f -0: /* Defaults to 256M */ lis r10, 0x1000 - bcl 20,31,$+4 +0: bcl 20,31,$+4 1: mflrr4 addir4, r4, (2f-1b) /* virtual address of 2f */ -- 2.47.0
Re: [PATCH] PCI/AER: Add kernel.aer_print_skip_mask to control aer log
[+cc Jon, Karolina]
On Wed, Jan 08, 2025 at 03:57:03PM +0800, Bijie Xu wrote:
> Sometimes certain PCIE devices installed on some servers occasionally
> produce large number of AER correctable error logs, which is quite
> annoying. Add this sysctl parameter kernel.aer_print_skip_mask to
> skip printing AER errors of certain severity.
>
> The AER severity can be 0(NONFATAL), 1(FATAL), 2(CORRECTABLE). The 3
> low bits of the mask are used to skip these 3 severities. Set bit 0
> can skip printing NONFATAL AER errors, and set bit 1 can skip printing
> FATAL AER errors, set bit 2 can skip printing CORRECTABLE AER errors.
> And multiple bits can be set to skip multiple severities.
This is definitely annoying, actually MORE than annoying in some
cases.
I'm hoping the correctable error rate-limiting work can reduce the
annoyance to an tolerable level:
https://lore.kernel.org/r/20250214023543.992372-1-pan...@google.com
Can you take a look at this and see if it's going the right direction
for you, or if it needs extensions to do what you need?
> Signed-off-by: Bijie Xu
> ---
> drivers/pci/pcie/aer.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 80c5ba8d8296..b46973526bcf 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -698,6 +698,7 @@ static void __aer_print_error(struct pci_dev *dev,
> pci_dev_aer_stats_incr(dev, info);
> }
>
> +unsigned int aer_print_skip_mask __read_mostly;
> void aer_print_error(struct pci_dev *dev, struct aer_err_info *info)
> {
> int layer, agent;
> @@ -710,6 +711,9 @@ void aer_print_error(struct pci_dev *dev, struct
> aer_err_info *info)
> goto out;
> }
>
> + if ((1 << info->severity) & aer_print_skip_mask)
> + goto out;
> +
> layer = AER_GET_LAYER_ERROR(info->severity, info->status);
> agent = AER_GET_AGENT(info->severity, info->status);
>
> @@ -1596,3 +1600,22 @@ int __init pcie_aer_init(void)
> return -ENXIO;
> return pcie_port_service_register(&aerdriver);
> }
> +
> +static const struct ctl_table aer_print_skip_mask_sysctls[] = {
> + {
> + .procname = "aer_print_skip_mask",
> + .data = &aer_print_skip_mask,
> + .maxlen = sizeof(unsigned int),
> + .mode = 0644,
> + .proc_handler = &proc_douintvec,
> + },
> + {}
> +};
> +
> +static int __init aer_print_skip_mask_sysctl_init(void)
> +{
> + register_sysctl_init("kernel", aer_print_skip_mask_sysctls);
> + return 0;
> +}
> +
> +late_initcall(aer_print_skip_mask_sysctl_init);
> --
> 2.25.1
>
Re: Build Warnings at arch/powerpc/
Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit : On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote: Greetings!! Observing build warnings with linux-next and powerpc repo's. Issue is currently not seen on mainline yet. PPC Repo: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585342184%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e5BrJzcrtlITkLF31KltGExQ5Qe8fDVTMV6VfR4w9o8%3D&reserved=0 merge branch PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1 next Repo: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585355246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=meQyZfB75HhJFCL6AX93slsyVwnogGPYFabDXl%2FLzDA%3D&reserved=0 master branch next Kernel Version: 6.14.0-rc5-next-20250303 On linux-next kernel issue got introduced b/w next-20250227 and next-20250303 Build Warnings: arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84: intra_function_call not a direct call arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated intra-function call arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call not a direct call Can you please specific the compiler and compiler version you found this issue with Can you also tell which defconfig you are using or provide your .config It might also be helpfull if you can provide a disassembly of the three file.o around the warned address. Christophe
[PATCH] AER: PCIE CTO recovery handle fix
[EXTERNAL EMAIL]
From 5fc7b1a9e0f0bcfa14068c6358019ed1e3ffc6c6 Mon Sep 17 00:00:00 2001
From: "dio.sun"
Date: Wed, 26 Feb 2025 08:54:49 +
Subject: [PATCH] AER: PCIE CTO recovery handle fix
- Non-fatal PCIe CTO is reportted to PCIE RC and it will be convertted to
AdvNonFatalErr automatically
- according to PCIE SPEC 6.2.3.2.4.4 Requester with Completion Timeout(
If the severity of the CTO is non-fatal, and the Requester elects to
attempt recovery by issuing a new request, the Requester must
first handle the currecnt error case as an Advisory Non-Fatal Error.).
- Current Kernel code does nothing when receiving an AdvNonFatalErr(
Correctable Error) and the device driver has no chance to handle this
error.
- Under this situation, sometimes system will hang when more
AdvNonFatalErr coming.
Signed-off-by: dio.sun
---
drivers/pci/pcie/aer.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 508474e17183..5ddc990c6f42 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1154,7 +1154,21 @@ static void aer_recover_work_func(struct work_struct
*work)
ghes_estatus_pool_region_free((unsigned long)entry.regs,
sizeof(struct aer_capability_regs));
- if (entry.severity == AER_NONFATAL)
+ if (entry.severity == AER_CORRECTABLE) {
+ if (entry.regs->cor_status & PCI_ERR_COR_ADV_NFAT) {
+ pci_err(pdev, "%04x:%02x:%02x:%x advisory
non-fatal error\n",
+ entry.domain, entry.bus,
PCI_SLOT(entry.devfn),
+ PCI_FUNC(entry.devfn));
+ if (entry.regs->uncor_status &
PCI_ERR_UNC_COMP_TIME) {
+ pci_err(pdev, "%04x:%02x:%02x:%x
completion timeout\n",
+ entry.domain, entry.bus,
+ PCI_SLOT(entry.devfn),
+ PCI_FUNC(entry.devfn));
+ pcie_do_recovery(pdev,
pci_channel_io_frozen,
+
aer_root_reset);
+ }
+ }
+ } else if (entry.severity == AER_NONFATAL)
pcie_do_recovery(pdev, pci_channel_io_normal,
aer_root_reset);
else if (entry.severity == AER_FATAL)
--
2.37.3
0001-AER-PCIE-CTO-recovery-handle-fix.patch
Description: 0001-AER-PCIE-CTO-recovery-handle-fix.patch
Re: Build Warnings at arch/powerpc/
On 3/4/25 2:26 PM, Christophe Leroy wrote: > > > Le 04/03/2025 à 07:13, Madhavan Srinivasan a écrit : >> >> >> On 3/4/25 10:42 AM, Venkat Rao Bagalkote wrote: >>> Greetings!! >>> >>> >>> Observing build warnings with linux-next and powerpc repo's. Issue is >>> currently not seen on mainline yet. >>> >>> PPC Repo: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpowerpc%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585342184%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e5BrJzcrtlITkLF31KltGExQ5Qe8fDVTMV6VfR4w9o8%3D&reserved=0 >>> merge branch >>> >>> PPC Kernel Version: 6.14.0-rc4-g1304f486dbf1 >>> next Repo: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C8e0f8501f09c48dbb43608dd5ae3c9bf%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638766656585355246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=meQyZfB75HhJFCL6AX93slsyVwnogGPYFabDXl%2FLzDA%3D&reserved=0 >>> master branch >>> >>> next Kernel Version: 6.14.0-rc5-next-20250303 >>> >>> >>> On linux-next kernel issue got introduced b/w next-20250227 and >>> next-20250303 >>> >>> >>> Build Warnings: >>> >>> arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84: >>> intra_function_call not a direct call >>> arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: >>> unannotated intra-function call >>> arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: >>> intra_function_call not a direct call >>> >>> >> >> Can you please specific the compiler and compiler version you found this >> issue with >> > > Can you also tell which defconfig you are using or provide your .config > > It might also be helpfull if you can provide a disassembly of the three > file.o around the warned address. I could recreate the issue with gcc 11.4.1 20231218 with today's linux-next (but could not recreate with gcc 14 or gcc 11.3.0) (20d5c66e1810 (HEAD -> master, tag: next-20250304, origin/master, origin/HEAD) Add linux-next specific files for 20250304) warning for one of the switch.S file : CC arch/powerpc/kernel/syscalls.o AS arch/powerpc/kernel/switch.o arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call not a direct call CC arch/powerpc/kernel/irq.o CC arch/powerpc/kernel/align.o CC arch/powerpc/kernel/signal_64.o Objdump of switch.o: arch/powerpc/kernel/switch.o: file format elf64-powerpcle Disassembly of section .text: : 0: a6 02 28 7d mflrr9 4: 05 00 00 48 bl 8 8: 05 00 00 48 bl c c: 05 00 00 48 bl 10 10: 05 00 00 48 bl 14 14: 05 00 00 48 bl 18 18: 05 00 00 48 bl 1c 1c: 05 00 00 48 bl 20 20: 05 00 00 48 bl 24 24: 05 00 00 48 bl 28 28: 05 00 00 48 bl 2c arch/powerpc/kernel/switch.S failing src section: .balign 32 .global flush_branch_caches flush_branch_caches: /* Save LR into r9 */ mflrr9 // Flush the link stack .rept 64 ANNOTATE_INTRA_FUNCTION_CALL bl .+4 .endr b 1f nops6 Maddy > > Christophe
Re: [PATCH v11 3/4] arm64: topology: Support SMT control on ACPI based system
On Tue, Mar 04, 2025 at 09:25:02AM +0100, Pierre Gondois wrote:
>
>
> On 3/3/25 15:40, Yicong Yang wrote:
> > On 2025/3/3 19:16, Sudeep Holla wrote:
> > > On Mon, Mar 03, 2025 at 10:56:12AM +0100, Pierre Gondois wrote:
> > > > On 2/28/25 20:06, Sudeep Holla wrote:
> > > > > > >
> > > > > > > Ditto as previous patch, can get rid if it is default 1.
> > > > > > >
> > > > > >
> > > > > > On non-SMT platforms, not calling cpu_smt_set_num_threads() leaves
> > > > > > cpu_smt_num_threads uninitialized to UINT_MAX:
> > > > > >
> > > > > > smt/active:0
> > > > > > smt/control:-1
> > > > > >
> > > > > > If cpu_smt_set_num_threads() is called:
> > > > > > active:0
> > > > > > control:notsupported
> > > > > >
> > > > > > So it might be slightly better to still initialize
> > > > > > max_smt_thread_num.
> > > > > >
> > > > >
> > > > > Sure, what I meant is to have max_smt_thread_num set to 1 by default
> > > > > is
> > > > > that is what needed anyways and the above code does that now.
> > > > >
> > > > > Why not start with initialised to 1 instead ?
> > > > > Of course some current logic needs to change around testing it for
> > > > > zero.
> > > > >
> > > >
> > > > I think there would still be a way to check against the default value.
> > > > If we have:
> > > > unsigned int max_smt_thread_num = 1;
> > > >
> > > > then on a platform with 2 threads, the detection condition would
> > > > trigger:
> > > > xa_for_each(&hetero_cpu, hetero_id, entry) {
> > > > if (entry->thread_num != max_smt_thread_num && max_smt_thread_num)
> > > > < (entry->thread_num=2) and (max_smt_thread_num=1)
> > > > pr_warn_once("Heterogeneous SMT topology is partly
> > > >supported by SMT control\n");
> > > >
> > > > so we would need an additional variable:
> > > > bool is_initialized = false;
> > >
> > > Sure, we could do that or skip the check if max_smt_thread_num == 1 ?
> > >
> > > I mean
> > > if (entry->thread_num != max_smt_thread_num && max_smt_thread_num != 1)
> > >
>
> I think it will be problematic if we parse:
> - first a CPU with 1 thread
> - then a CPU with 2 threads
>
> in that case we should detect the 'Heterogeneous SMT topology',
> but we cannot because we don't know whether max_smt_thread_num=1
> because 1 is the default value or we found a CPU with one thread.
Right, but as per Dietmar's and my previous response, it may be a valid
case. See latest response from Dietmar which is explicitly requesting
support for this. It may need some special handling if we decide to support
that.
--
Regards,
Sudeep
Re: [PATCH v11 2/4] arch_topology: Support SMT control for OF based system
On 03/03/2025 15:03, Yicong Yang wrote:
> On 2025/2/28 19:11, Dietmar Eggemann wrote:
>> On 18/02/2025 15:10, Yicong Yang wrote:
>>> From: Yicong Yang
[...]
>>> If a system have more than one SMT thread number the 2) may
>>
>> s/have/has
>>
>>> not handle it well, since there're multiple thread numbers in the
>>
>> multiple thread numbers other than 1, right?
>
> according to the pr_warn_once() we implemented below it also includes the case
> where the system have one type of SMT cores and non-SMT cores (the thread
> number is 1):
> - 1 thread
> - X (!= 1) threads
>
> Discussion made in [1] and I thought we have agreement (hope I understood
> correctly)
> that all the asymmetric cases need to notify. Do you and Sudeep think we
> should not
> warn in such case?
Systems with non-SMT and SMT-2 cores are IMHO a special case since for
them the '/sys/devices/system/cpu/smt' interface still works correctly.
And on X86 those systems do exist today.
IMHO, it would be awkward to see the message 'Heterogeneous SMT topology
is partly supported by SMT control' on arm64 but not on x86 on such a
system.
I do understand that this message is more tailored to theoretically
possible 'multiple SMT-X (X>1) core' systems (e.g. 1,2,4).
And here we cannot issue a '2 > ./control' since
cpu_smt_num_threads_valid() only returns true for 1 or 4.
IMHO, I would remove the warning and state clearly in the patch that for
systems with multiple SMT-X (X>1) cores, this interface only support SMT
completely on or off.
Example Arm64 DT:
cpu-map {
cluster0 {
core0 {
thread0 {
cpu = <&A53_0>;
};
};
core1 {
thread0 {
cpu = <&A53_1>;
};
};
core2 {
thread0 {
cpu = <&A53_2>;
};
thread1 {
cpu = <&A53_3>;
};
};
core3 {
thread0 {
cpu = <&A53_4>;
};
thread1 {
cpu = <&A53_5>;
};
thread2 {
cpu = <&A53_6>;
};
thread3 {
cpu = <&A53_7>;
};
};
};
};
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
/sys/devices/system/cpu/smt# echo 1 >control
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 4
/sys/devices/system/cpu/smt# echo 2 >control
-bash: echo: write error: Invalid argument
[...]
Re: [PATCH 0/4] ASoC: fsl_audmix: support audio graph card for audmix
On Wed, 26 Feb 2025 18:05:04 +0800, Shengjiu Wang wrote: > Change 'dais' property to be optional, that fsl_audmix device can be > linked with SAI device by audio graph card. > > Shengjiu Wang (4): > ASoC: dt-bindings: fsl,sai: Document audio graph port > ASoC: dt-bindings: fsl,audmix: Document audio graph port > ASoC: dt-bindings: fsl,audmix: make 'dais' property to be optional > ASoC: fsl_audmix: register card device depends on 'dais' property > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/4] ASoC: dt-bindings: fsl,sai: Document audio graph port commit: abcb9a1fd89144536f3ef604f700e94424867366 [2/4] ASoC: dt-bindings: fsl,audmix: Document audio graph port commit: 5fee78e517ce0765def9387659fc56a1d5532c60 [3/4] ASoC: dt-bindings: fsl,audmix: make 'dais' property to be optional commit: 597acf1a04bede55e3ad8a7922bba286c2d3 [4/4] ASoC: fsl_audmix: register card device depends on 'dais' property commit: 294a60e5e9830045c161181286d44ce669f88833 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] powerpc: Fix 'intra_function_call not a direct call' warning
Hello Christophe,
On 05/03/25 4:30 am, Christophe Leroy wrote:
The following build warning have been reported:
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
intra_function_call not a direct call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4:
intra_function_call not a direct call
This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support
for decoding all types of uncond branches") because that commit decodes
'bl .+4' as a normal instruction because that instruction is used by
clang instead of 'bcl 20,31,+.4' for relocatable code.
The solution is simply to remove the ANNOTATE_INTRA_FUNCTION_CALL
annotation now that the instruction is not seen as a function call
anymore.
Reported-by: Venkat Rao Bagalkote
Closes:
https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d611...@linux.ibm.com
Fixes: bb7f054f4de2 ("objtool/powerpc: Add support for decoding all types of uncond
branches")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/switch.S| 1 -
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/switch.S b/arch/powerpc/kernel/switch.S
index 608c0ce7cec6..59e3ee99db0e 100644
--- a/arch/powerpc/kernel/switch.S
+++ b/arch/powerpc/kernel/switch.S
@@ -39,7 +39,6 @@ flush_branch_caches:
// Flush the link stack
.rept 64
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
b 1f
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index ea7ad200b330..83f7504349d2 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1524,14 +1524,12 @@ kvm_flush_link_stack:
/* Flush the link stack. On Power8 it's up to 32 entries in size. */
.rept 32
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
/* And on Power9 it's up to 64. */
BEGIN_FTR_SECTION
.rept 32
- ANNOTATE_INTRA_FUNCTION_CALL
bl .+4
.endr
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
Applied this patch on top of linux-next 20250303, and it fixes the below
reported warning.
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe84:
intra_function_call not a direct call
arch/powerpc/kernel/switch.o: warning: objtool: .text+0x4: intra_function_call
not a direct call
Please add below tag:
Tested-By: Venkat Rao Bagalkote
Regards,
Venkat.
Re: [PATCH] crypto: powerpc: Mark ghashp8-ppc.o as an OBJECT_FILES_NON_STANDARD
Hello Christophe,
On 05/03/25 4:32 am, Christophe Leroy wrote:
The following build warning has been reported:
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c:
unannotated intra-function call
This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support
for decoding all types of uncond branches")
Disassembly of arch/powerpc/crypto/ghashp8-ppc.o shows:
arch/powerpc/crypto/ghashp8-ppc.o: file format elf64-powerpcle
Disassembly of section .text:
0140 :
140:f8 ff 00 3c lis r0,-8
...
20c:20 00 80 4e blr
210:00 00 00 00 .long 0x0
214:00 0c 14 00 .long 0x140c00
218:00 00 04 00 .long 0x4
21c:00 00 00 00 .long 0x0
220:47 48 41 53 rlwimi. r1,r26,9,1,3
224:48 20 66 6f xoris r6,r27,8264
228:72 20 50 6f xoris r16,r26,8306
22c:77 65 72 49 bla 1726574 <==
...
It corresponds to the following code in ghashp8-ppc.o :
_GLOBAL(gcm_ghash_p8)
lis0,0xfff8
...
blr
.long0
.byte0,12,0x14,0,0,0,4,0
.long0
.sizegcm_ghash_p8,.-gcm_ghash_p8
.byte
71,72,65,83,72,32,102,111,114,32,80,111,119,101,114,73,83,65,32,50,46,48,55,44,32,67,82,89,80,84,79,71,65,77,83,32,98,121,32,60,97,112,112,114,111,64,111,112,101,110,115,115,108,46,111,114,103,62,0
.align2
.align2
In fact this is raw data that is after the function end and that is
not text so shouldn't be disassembled as text. But ghashp8-ppc.S is
generated by a perl script and should have been marked as
OBJECT_FILES_NON_STANDARD.
Now that 'bla' is understood as a call instruction, that raw data
is mis-interpreted as an infra-function call.
Mark ghashp8-ppc.o as a OBJECT_FILES_NON_STANDARD to avoid this
warning.
Reported-by: Venkat Rao Bagalkote
Closes:
https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d611...@linux.ibm.com
Cc: Danny Tsen
Fixes: 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto")
Signed-off-by: Christophe Leroy
---
arch/powerpc/crypto/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/crypto/Makefile b/arch/powerpc/crypto/Makefile
index 9b38f4a7bc15..2f00b22b0823 100644
--- a/arch/powerpc/crypto/Makefile
+++ b/arch/powerpc/crypto/Makefile
@@ -51,3 +51,4 @@ $(obj)/aesp8-ppc.S $(obj)/ghashp8-ppc.S: $(obj)/%.S:
$(src)/%.pl FORCE
OBJECT_FILES_NON_STANDARD_aesp10-ppc.o := y
OBJECT_FILES_NON_STANDARD_ghashp10-ppc.o := y
OBJECT_FILES_NON_STANDARD_aesp8-ppc.o := y
+OBJECT_FILES_NON_STANDARD_ghashp8-ppc.o := y
Applied this patch on top of linux-next 20250303, and it fixes the below
reported warning.
arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated
intra-function call.
Please add below tag:
Tested-By: Venkat Rao Bagalkote
Regards,
Venkat.
