* [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
@ 2025-04-01 2:44 kernel test robot
2025-04-01 4:38 ` Philip Li
0 siblings, 1 reply; 11+ messages in thread
From: kernel test robot @ 2025-04-01 2:44 UTC (permalink / raw)
To: Guenter Roeck
Cc: oe-kbuild-all, Andrew Morton, Linux Memory Management List,
Alessandro Carminati
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-01 2:44 [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24 kernel test robot
@ 2025-04-01 4:38 ` Philip Li
2025-04-01 19:45 ` Josh Poimboeuf
0 siblings, 1 reply; 11+ messages in thread
From: Philip Li @ 2025-04-01 4:38 UTC (permalink / raw)
To: kernel test robot
Cc: Guenter Roeck, oe-kbuild-all, Andrew Morton,
Linux Memory Management List, Alessandro Carminati
On Tue, Apr 01, 2025 at 10:44:57AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
> commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
> config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
> compiler: loongarch64-linux-gcc (GCC) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
FYI: not sure whether this is a false positive due to wrong bisection, as
there's fix [1] for 'stack state mismatch' issue.
arch/loongarch/kernel/traps.o: warning: objtool: show_stack+0xe0: stack state mismatch: reg1[22]=-1+0 reg2[22]=-2-160
arch/loongarch/kernel/traps.o: warning: objtool: show_stack+0xe0: stack state mismatch: reg1[23]=-1+0 reg2[23]=-2-152
[1] https://lore.kernel.org/all/270cadd8040dda74db2307f23497bb68e65db98d.1743481539.git.jpoimboe@kernel.org/
>
> >> drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-01 4:38 ` Philip Li
@ 2025-04-01 19:45 ` Josh Poimboeuf
2025-04-03 9:35 ` Tiezhu Yang
0 siblings, 1 reply; 11+ messages in thread
From: Josh Poimboeuf @ 2025-04-01 19:45 UTC (permalink / raw)
To: Philip Li, Tiezhu Yang
Cc: kernel test robot, Guenter Roeck, oe-kbuild-all, Andrew Morton,
Linux Memory Management List, Alessandro Carminati,
Peter Zijlstra, linux-kernel, loongarch
On Tue, Apr 01, 2025 at 12:38:37PM +0800, Philip Li wrote:
> On Tue, Apr 01, 2025 at 10:44:57AM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
> > commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
> > config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
> > compiler: loongarch64-linux-gcc (GCC) 14.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
Tiezhu, this looks like a loongarch GCC bug with asm goto, or am I
confused? See analysis below.
make-loongarch -j12 -s drivers/i2c/i2c-core-base.o OBJTOOL_ARGS="--sec-address --backtrace"
drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120 (.text+0x2e78): stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x168 (.text+0x2ec0): (alt)
drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x6c (.text+0x2dc4): (branch)
drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x58 (.text+0x2db0): (alt)
drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x44 (.text+0x2d9c): (branch)
drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x0 (.text+0x2d58): <=== (sym)
Below I reconstructed the code path indicated by the above backtrace.
(On a side note, I wonder why the toolchain doesn't strip the ".L" local
symbols, they're rather distracting.)
Here's the jump table to explain the static branches below:
Relocation section '.rela__jump_table' at offset 0xc7f0 contains 9 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 00000a6d00000063 R_LARCH_32_PCREL 0000000000002db0 .L1^B1 + 0
0000000000000004 00000a6e00000063 R_LARCH_32_PCREL 0000000000002db4 .L849 + 0
0000000000000008 0000059c0000006d R_LARCH_64_PCREL 0000000000000010 i2c_trace_msg_key + 0
0000000000000010 00000a6f00000063 R_LARCH_32_PCREL 0000000000002e64 .L1^B2 + 0
0000000000000014 00000a7000000063 R_LARCH_32_PCREL 0000000000002e78 .L845 + 0
0000000000000018 0000059c0000006d R_LARCH_64_PCREL 0000000000000010 i2c_trace_msg_key + 0
0000000000000020 00000a7100000063 R_LARCH_32_PCREL 0000000000002ec0 .L1^B3 + 0
0000000000000024 00000a7000000063 R_LARCH_32_PCREL 0000000000002e78 .L845 + 0
0000000000000028 0000059c0000006d R_LARCH_64_PCREL 0000000000000010 i2c_trace_msg_key + 0
---------------
start execution
---------------
0000000000002d58 <__i2c_transfer>:
2d58: 02fe8063 addi.d $sp, $sp, -96
2d5c: 29c14077 st.d $s0, $sp, 80
2d60: 29c16061 st.d $ra, $sp, 88
2d64: 28c0408c ld.d $t0, $a0, 16
2d68: 00150097 move $s0, $a0
2d6c: 2600018c ldptr.d $t0, $t0, 0
2d70: 40021980 beqz $t0, 536 # 2f88 <.LVL1023>
2d74: 29c12078 st.d $s1, $sp, 72
2d78: 001500b8 move $s1, $a1
-----------------------
$s1 saved and clobbered
-----------------------
0000000000002d7c <.LBB2114>:
2d7c: 400150a0 beqz $a1, 336 # 2ecc <.LVL999+0x4>
2d80: 29c10079 st.d $s2, $sp, 64
2d84: 001500d9 move $s2, $a2
-----------------------
$s2 saved and clobbered
-----------------------
2d88: 64014006 blez $a2, 320 # 2ec8 <.LVL999>
0000000000002d8c <.LBB2115>:
2d8c: 28c9a08c ld.d $t0, $a0, 616
2d90: 0340058c andi $t0, $t0, 0x1
2d94: 44016180 bnez $t0, 352 # 2ef4 <.LBB2119>
0000000000002d98 <.LVL978>:
2d98: 28cc008c ld.d $t0, $a0, 768
2d9c: 40000d80 beqz $t0, 12 # 2da8 <.LVL979+0x4>
--------------
branch -> 2da8 (adal->quirks == NULL)
--------------
2da8: 29c0e07a st.d $s3, $sp, 56
2dac: 29c0607e st.d $s7, $sp, 24
-----------------
$s3 and $s7 saved
-----------------
0000000000002db0 <.L1^B1>:
2db0: 03400000 nop
---------------------
static branch -> 2db4 (i2c_trace_msg_key enabled; branch to next insn
b/c clause is empty due to !CONFIG_TRACEPOINTS)
---------------------
0000000000002db4 <.L849>:
2db4: 1a00001a pcalau12i $s3, 0 2db4: R_LARCH_GOT_PC_HI20 jiffies
-------------
$s3 clobbered
-------------
2db8: 28c0035a ld.d $s3, $s3, 0 2db8: R_LARCH_GOT_PC_LO12 jiffies
2dbc: 24006eec ldptr.w $t0, $s0, 108
2dc0: 2600035e ldptr.d $s7, $s3, 0
-------------
$s7 clobbered
-------------
0000000000002dc4 <.LVL982>:
2dc4: 6000f980 bltz $t0, 248 # 2ebc <.LVL997>
--------------
branch -> 2ebc (adap->retries < 0)
--------------
0000000000002ebc <.LVL997>:
2ebc: 00150004 move $a0, $zero
0000000000002ec0 <.L1^B3>:
2ec0: 03400000 nop
-----------------------------
BROKEN: static branch -> 2e78 (i2c_trace_msg_key enabled; again tries to
skip empty tracepoint clause but branches
to the wrong place in epilogue, skipping
reg restores of callee saved registers
$s1, $s2, $s3, $s7)
-----------------------------
0000000000002e78 <.L845>:
2e78: 28c16061 ld.d $ra, $sp, 88
2e7c: 28c14077 ld.d $s0, $sp, 80
0000000000002e80 <.LVL994>:
2e80: 02c18063 addi.d $sp, $sp, 96
--------------------------------------
return without restoring $s1, $s2, $s3
--------------------------------------
2e84: 4c000020 ret
Full disassembly below:
0000000000002d58 <__i2c_transfer>:
2d58: 02fe8063 addi.d $sp, $sp, -96
2d5c: 29c14077 st.d $s0, $sp, 80
2d60: 29c16061 st.d $ra, $sp, 88
2d64: 28c0408c ld.d $t0, $a0, 16
2d68: 00150097 move $s0, $a0
2d6c: 2600018c ldptr.d $t0, $t0, 0
2d70: 40021980 beqz $t0, 536 # 2f88 <.LVL1023>
2d74: 29c12078 st.d $s1, $sp, 72
2d78: 001500b8 move $s1, $a1
0000000000002d7c <.LBB2114>:
2d7c: 400150a0 beqz $a1, 336 # 2ecc <.LVL999+0x4>
2d80: 29c10079 st.d $s2, $sp, 64
2d84: 001500d9 move $s2, $a2
2d88: 64014006 blez $a2, 320 # 2ec8 <.LVL999>
0000000000002d8c <.LBB2115>:
2d8c: 28c9a08c ld.d $t0, $a0, 616
2d90: 0340058c andi $t0, $t0, 0x1
2d94: 44016180 bnez $t0, 352 # 2ef4 <.LBB2119>
0000000000002d98 <.LVL978>:
2d98: 28cc008c ld.d $t0, $a0, 768
2d9c: 40000d80 beqz $t0, 12 # 2da8 <.LVL979+0x4>
2da0: 57fcdbff bl -808 # 2a78 <i2c_check_for_quirks>
0000000000002da4 <.LVL979>:
2da4: 44018480 bnez $a0, 388 # 2f28 <.LVL1010>
2da8: 29c0e07a st.d $s3, $sp, 56
2dac: 29c0607e st.d $s7, $sp, 24
0000000000002db0 <.L1^B1>:
2db0: 03400000 nop
0000000000002db4 <.L849>:
2db4: 1a00001a pcalau12i $s3, 0 2db4: R_LARCH_GOT_PC_HI20 jiffies
2db8: 28c0035a ld.d $s3, $s3, 0 2db8: R_LARCH_GOT_PC_LO12 jiffies
2dbc: 24006eec ldptr.w $t0, $s0, 108
2dc0: 2600035e ldptr.d $s7, $s3, 0
0000000000002dc4 <.LVL982>:
2dc4: 6000f980 bltz $t0, 248 # 2ebc <.LVL997>
2dc8: 29c0c07b st.d $s4, $sp, 48
2dcc: 1a00001b pcalau12i $s4, 0 2dcc: R_LARCH_GOT_PC_HI20 system_state
2dd0: 29c0a07c st.d $s5, $sp, 40
2dd4: 29c0807d st.d $s6, $sp, 32
2dd8: 29c0407f st.d $s8, $sp, 16
0000000000002ddc <.LBB2138>:
2ddc: 02800c1d li.w $s6, 3
2de0: 0015001f move $s8, $zero
2de4: 02bfd41c li.w $s5, -11
2de8: 28c0037b ld.d $s4, $s4, 0 2de8: R_LARCH_GOT_PC_LO12 system_state
0000000000002dec <.LVL983>:
2dec: 03400000 nop
0000000000002df0 <.LBI2138>:
2df0: 2400036c ldptr.w $t0, $s4, 0
2df4: 6c00afac bgeu $s6, $t0, 172 # 2ea0 <.LVL995+0x18>
0000000000002df8 <.LBB2140>:
2df8: 24001c4c ldptr.w $t0, $tp, 28
2dfc: 0040818c slli.w $t0, $t0, 0x0
2e00: 44001180 bnez $t0, 16 # 2e10 <.LVL984+0x8>
0000000000002e04 <.LBB2145>:
2e04: 0400000c csrrd $t0, 0x0
0000000000002e08 <.LVL984>:
2e08: 0340118c andi $t0, $t0, 0x4
2e0c: 44009580 bnez $t0, 148 # 2ea0 <.LVL995+0x18>
2e10: 28c042ec ld.d $t0, $s0, 16
2e14: 28c0218d ld.d $t1, $t0, 8
2e18: 40008da0 beqz $t1, 140 # 2ea4 <.LVL995+0x1c>
2e1c: 00150326 move $a2, $s2
2e20: 00150305 move $a1, $s1
2e24: 001502e4 move $a0, $s0
2e28: 4c0001a1 jirl $ra, $t1, 0
0000000000002e2c <.LVL987>:
2e2c: 5c00289c bne $a0, $s5, 40 # 2e54 <.LVL988+0x4>
0000000000002e30 <.LBB2152>:
2e30: 29c02060 st.d $zero, $sp, 8
2e34: 2600034d ldptr.d $t1, $s3, 0
2e38: 24006aec ldptr.w $t0, $s0, 104
2e3c: 0011b7cd sub.d $t1, $s7, $t1
2e40: 0010b58c add.d $t0, $t0, $t1
2e44: 60001180 bltz $t0, 16 # 2e54 <.LVL988+0x4>
2e48: 24006eec ldptr.w $t0, $s0, 108
2e4c: 028007ff addi.w $s8, $s8, 1
0000000000002e50 <.LVL988>:
2e50: 67ffa19f bge $t0, $s8, -96 # 2df0 <.LBI2138>
2e54: 28c0c07b ld.d $s4, $sp, 48
2e58: 28c0a07c ld.d $s5, $sp, 40
2e5c: 28c0807d ld.d $s6, $sp, 32
2e60: 28c0407f ld.d $s8, $sp, 16
0000000000002e64 <.L1^B2>:
2e64: 03400000 nop
2e68: 28c12078 ld.d $s1, $sp, 72
0000000000002e6c <.LVL991>:
2e6c: 28c10079 ld.d $s2, $sp, 64
0000000000002e70 <.LVL992>:
2e70: 28c0e07a ld.d $s3, $sp, 56
2e74: 28c0607e ld.d $s7, $sp, 24
0000000000002e78 <.L845>:
2e78: 28c16061 ld.d $ra, $sp, 88
2e7c: 28c14077 ld.d $s0, $sp, 80
0000000000002e80 <.LVL994>:
2e80: 02c18063 addi.d $sp, $sp, 96
2e84: 4c000020 ret
0000000000002e88 <.LVL995>:
2e88: 03400000 nop
2e8c: 03400000 nop
2e90: 03400000 nop
2e94: 03400000 nop
2e98: 03400000 nop
2e9c: 03400000 nop
2ea0: 28c042ec ld.d $t0, $s0, 16
2ea4: 2600018c ldptr.d $t0, $t0, 0
2ea8: 00150326 move $a2, $s2
2eac: 00150305 move $a1, $s1
2eb0: 001502e4 move $a0, $s0
2eb4: 4c000181 jirl $ra, $t0, 0
0000000000002eb8 <.LVL996>:
2eb8: 53ff77ff b -140 # 2e2c <.LVL987>
0000000000002ebc <.LVL997>:
2ebc: 00150004 move $a0, $zero
0000000000002ec0 <.L1^B3>:
2ec0: 03400000 nop
2ec4: 53ffa7ff b -92 # 2e68 <.L1^B2+0x4>
0000000000002ec8 <.LVL999>:
2ec8: 28c10079 ld.d $s2, $sp, 64
2ecc: 1a000004 pcalau12i $a0, 0 2ecc: R_LARCH_PCALA_HI20 .LANCHOR0
0000000000002ed0 <.LVL1000>:
2ed0: 02c00084 addi.d $a0, $a0, 0 2ed0: R_LARCH_PCALA_LO12 .LANCHOR0
2ed4: 02c5a084 addi.d $a0, $a0, 360
2ed8: 54000000 bl 0 # 2ed8 <.LVL1000+0x8> 2ed8: R_LARCH_B26 __kunit_is_suppressed_warning
0000000000002edc <.LVL1001>:
2edc: 0015008c move $t0, $a0
2ee0: 02bfa804 li.w $a0, -22
2ee4: 44003d80 bnez $t0, 60 # 2f20 <.LVL1008+0x8>
0000000000002ee8 <.L10001^B7>:
2ee8: 002a0001 break 0x1
2eec: 28c12078 ld.d $s1, $sp, 72
0000000000002ef0 <.LVL1002>:
2ef0: 53ff8bff b -120 # 2e78 <.L845>
0000000000002ef4 <.LBB2119>:
2ef4: 0280080d li.w $t1, 2
2ef8: 02c9a08e addi.d $t2, $a0, 616
2efc: 386cb5cc amor_db.d $t0, $t1, $t2
0000000000002f00 <.LVL1004>:
2f00: 0340098c andi $t0, $t0, 0x2
2f04: 40003580 beqz $t0, 52 # 2f38 <.LBB2126>
0000000000002f08 <.LVL1006>:
2f08: 28c12078 ld.d $s1, $sp, 72
2f0c: 28c10079 ld.d $s2, $sp, 64
0000000000002f10 <.LVL1007>:
2f10: 02be5004 li.w $a0, -108
2f14: 53ff67ff b -156 # 2e78 <.L845>
0000000000002f18 <.LVL1008>:
2f18: 03400000 nop
2f1c: 03400000 nop
2f20: 28c12078 ld.d $s1, $sp, 72
0000000000002f24 <.LVL1009>:
2f24: 53ff57ff b -172 # 2e78 <.L845>
0000000000002f28 <.LVL1010>:
2f28: 28c12078 ld.d $s1, $sp, 72
0000000000002f2c <.LVL1011>:
2f2c: 28c10079 ld.d $s2, $sp, 64
0000000000002f30 <.LVL1012>:
2f30: 02be8404 li.w $a0, -95
2f34: 53ff47ff b -188 # 2e78 <.L845>
0000000000002f38 <.LBB2126>:
2f38: 1a000018 pcalau12i $s1, 0 2f38: R_LARCH_PCALA_HI20 .LANCHOR0
2f3c: 02c00318 addi.d $s1, $s1, 0 2f3c: R_LARCH_PCALA_LO12 .LANCHOR0
2f40: 02c5e318 addi.d $s1, $s1, 376
2f44: 00150304 move $a0, $s1
0000000000002f48 <.LVL1014>:
2f48: 54000000 bl 0 # 2f48 <.LVL1014> 2f48: R_LARCH_B26 __kunit_is_suppressed_warning
0000000000002f4c <.LVL1015>:
2f4c: 47ffbc9f bnez $a0, -68 # 2f08 <.LVL1006>
2f50: 02c1c2e4 addi.d $a0, $s0, 112
2f54: 54000000 bl 0 # 2f54 <.LVL1015+0x8> 2f54: R_LARCH_B26 dev_driver_string
0000000000002f58 <.LBB2127>:
2f58: 28c302e6 ld.d $a2, $s0, 192
2f5c: 00150085 move $a1, $a0
0000000000002f60 <.LBI2127>:
2f60: 440008c0 bnez $a2, 8 # 2f68 <.LBB2129+0x4>
0000000000002f64 <.LBB2129>:
2f64: 28c1c2e6 ld.d $a2, $s0, 112
2f68: 1a000004 pcalau12i $a0, 0 2f68: R_LARCH_PCALA_HI20 .LC70
2f6c: 02c00084 addi.d $a0, $a0, 0 2f6c: R_LARCH_PCALA_LO12 .LC70
2f70: 54000000 bl 0 # 2f70 <.LBB2129+0xc> 2f70: R_LARCH_B26 __warn_printk
0000000000002f74 <.LVL1020>:
2f74: 00150304 move $a0, $s1
2f78: 54000000 bl 0 # 2f78 <.LVL1020+0x4> 2f78: R_LARCH_B26 __kunit_is_suppressed_warning
0000000000002f7c <.LVL1021>:
2f7c: 47ff8c9f bnez $a0, -116 # 2f08 <.LVL1006>
0000000000002f80 <.L10001^B8>:
2f80: 002a0001 break 0x1
0000000000002f84 <.LVL1022>:
2f84: 53ff87ff b -124 # 2f08 <.LVL1006>
0000000000002f88 <.LVL1023>:
2f88: 1a000006 pcalau12i $a2, 0 2f88: R_LARCH_PCALA_HI20 .LC69
0000000000002f8c <.LVL1024>:
2f8c: 1a000004 pcalau12i $a0, 0 2f8c: R_LARCH_PCALA_HI20 .LC9
0000000000002f90 <.LVL1025>:
2f90: 02c00084 addi.d $a0, $a0, 0 2f90: R_LARCH_PCALA_LO12 .LC9
2f94: 02c1c2e5 addi.d $a1, $s0, 112
0000000000002f98 <.LVL1026>:
2f98: 02c000c6 addi.d $a2, $a2, 0 2f98: R_LARCH_PCALA_LO12 .LC69
2f9c: 54000000 bl 0 # 2f9c <.LVL1026+0x4> 2f9c: R_LARCH_B26 _dev_printk
0000000000002fa0 <.LVL1027>:
2fa0: 02be8404 li.w $a0, -95
2fa4: 53fed7ff b -300 # 2e78 <.L845>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-01 19:45 ` Josh Poimboeuf
@ 2025-04-03 9:35 ` Tiezhu Yang
2025-04-03 9:40 ` Huacai Chen
2025-04-03 14:37 ` Josh Poimboeuf
0 siblings, 2 replies; 11+ messages in thread
From: Tiezhu Yang @ 2025-04-03 9:35 UTC (permalink / raw)
To: Josh Poimboeuf, Philip Li
Cc: kernel test robot, Guenter Roeck, oe-kbuild-all, Andrew Morton,
Linux Memory Management List, Alessandro Carminati,
Peter Zijlstra, linux-kernel, loongarch
On 04/02/2025 03:45 AM, Josh Poimboeuf wrote:
> On Tue, Apr 01, 2025 at 12:38:37PM +0800, Philip Li wrote:
>> On Tue, Apr 01, 2025 at 10:44:57AM +0800, kernel test robot wrote:
>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
>>> commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
>>> config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
>>> compiler: loongarch64-linux-gcc (GCC) 14.2.0
>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
>>>
>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>> the same patch/commit), kindly add following tags
>>> | Reported-by: kernel test robot <lkp@intel.com>
>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>>>> drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
>
> Tiezhu, this looks like a loongarch GCC bug with asm goto, or am I
> confused? See analysis below.
This is related with GCC optimization "-fshrink-wrap" which is default y
on LoongArch, use "-fno-shrink-wrap" can avoid such issues, like this:
---8<---
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index 0304eabbe606..2d5529322357 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -106,6 +106,7 @@ KBUILD_CFLAGS +=
-mannotate-tablejump
else
KBUILD_CFLAGS += -fno-jump-tables # keep
compatibility with older compilers
endif
+KBUILD_CFLAGS += -fno-shrink-wrap
endif
KBUILD_RUSTFLAGS +=
--target=loongarch64-unknown-none-softfloat -Ccode-model=small
If you are OK with this change, I will send a formal patch after the
merge window.
Thanks,
Tiezhu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-03 9:35 ` Tiezhu Yang
@ 2025-04-03 9:40 ` Huacai Chen
2025-04-03 14:37 ` Josh Poimboeuf
1 sibling, 0 replies; 11+ messages in thread
From: Huacai Chen @ 2025-04-03 9:40 UTC (permalink / raw)
To: Tiezhu Yang
Cc: Josh Poimboeuf, Philip Li, kernel test robot, Guenter Roeck,
oe-kbuild-all, Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On Thu, Apr 3, 2025 at 5:36 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 04/02/2025 03:45 AM, Josh Poimboeuf wrote:
> > On Tue, Apr 01, 2025 at 12:38:37PM +0800, Philip Li wrote:
> >> On Tue, Apr 01, 2025 at 10:44:57AM +0800, kernel test robot wrote:
> >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >>> head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
> >>> commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
> >>> config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
> >>> compiler: loongarch64-linux-gcc (GCC) 14.2.0
> >>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
> >>>
> >>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> >>> the same patch/commit), kindly add following tags
> >>> | Reported-by: kernel test robot <lkp@intel.com>
> >>> | Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
> >>>
> >>> All warnings (new ones prefixed by >>):
> >>>
> >>>>> drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
> >
> > Tiezhu, this looks like a loongarch GCC bug with asm goto, or am I
> > confused? See analysis below.
>
> This is related with GCC optimization "-fshrink-wrap" which is default y
> on LoongArch, use "-fno-shrink-wrap" can avoid such issues, like this:
>
> ---8<---
>
> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
> index 0304eabbe606..2d5529322357 100644
> --- a/arch/loongarch/Makefile
> +++ b/arch/loongarch/Makefile
> @@ -106,6 +106,7 @@ KBUILD_CFLAGS +=
> -mannotate-tablejump
> else
> KBUILD_CFLAGS += -fno-jump-tables # keep
> compatibility with older compilers
> endif
> +KBUILD_CFLAGS += -fno-shrink-wrap
> endif
>
> KBUILD_RUSTFLAGS +=
> --target=loongarch64-unknown-none-softfloat -Ccode-model=small
>
> If you are OK with this change, I will send a formal patch after the
> merge window.
Is this the same problem solved by the commit below?
https://web.git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=objtool/urgent&id=7c977393b8277ed319e92e4b598b26598c9d30c0
Huacai
>
> Thanks,
> Tiezhu
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-03 9:35 ` Tiezhu Yang
2025-04-03 9:40 ` Huacai Chen
@ 2025-04-03 14:37 ` Josh Poimboeuf
2025-04-07 10:52 ` Tiezhu Yang
1 sibling, 1 reply; 11+ messages in thread
From: Josh Poimboeuf @ 2025-04-03 14:37 UTC (permalink / raw)
To: Tiezhu Yang
Cc: Philip Li, kernel test robot, Guenter Roeck, oe-kbuild-all,
Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On Thu, Apr 03, 2025 at 05:35:51PM +0800, Tiezhu Yang wrote:
> On 04/02/2025 03:45 AM, Josh Poimboeuf wrote:
> > On Tue, Apr 01, 2025 at 12:38:37PM +0800, Philip Li wrote:
> > > On Tue, Apr 01, 2025 at 10:44:57AM +0800, kernel test robot wrote:
> > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > > head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
> > > > commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
> > > > config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
> > > > compiler: loongarch64-linux-gcc (GCC) 14.2.0
> > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
> > > >
> > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
> > > >
> > > > All warnings (new ones prefixed by >>):
> > > >
> > > > > > drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
> >
> > Tiezhu, this looks like a loongarch GCC bug with asm goto, or am I
> > confused? See analysis below.
>
> This is related with GCC optimization "-fshrink-wrap" which is default y
> on LoongArch, use "-fno-shrink-wrap" can avoid such issues, like this:
As I showed, it looks like an actual runtime bug, not an objtool false
positive. Disabling it only for CONFIG_OBJTOOLonly wouldn't fix that.
--
Josh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-03 14:37 ` Josh Poimboeuf
@ 2025-04-07 10:52 ` Tiezhu Yang
2025-04-08 1:23 ` Josh Poimboeuf
0 siblings, 1 reply; 11+ messages in thread
From: Tiezhu Yang @ 2025-04-07 10:52 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Philip Li, kernel test robot, Guenter Roeck, oe-kbuild-all,
Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On 04/03/2025 10:37 PM, Josh Poimboeuf wrote:
> On Thu, Apr 03, 2025 at 05:35:51PM +0800, Tiezhu Yang wrote:
>> On 04/02/2025 03:45 AM, Josh Poimboeuf wrote:
>>> On Tue, Apr 01, 2025 at 12:38:37PM +0800, Philip Li wrote:
>>>> On Tue, Apr 01, 2025 at 10:44:57AM +0800, kernel test robot wrote:
>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>>> head: 405e2241def89c88f008dcb899eb5b6d4be8b43c
>>>>> commit: 9016dad4dca4bbe61c48ffd5a273cad980caa0d1 [12681/13861] loongarch: add support for suppressing warning backtraces
>>>>> config: loongarch-randconfig-001-20250401 (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/config)
>>>>> compiler: loongarch64-linux-gcc (GCC) 14.2.0
>>>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250401/202504011011.jyZ6NtXx-lkp@intel.com/reproduce)
>>>>>
>>>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>>>> the same patch/commit), kindly add following tags
>>>>> | Reported-by: kernel test robot <lkp@intel.com>
>>>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202504011011.jyZ6NtXx-lkp@intel.com/
>>>>>
>>>>> All warnings (new ones prefixed by >>):
>>>>>
>>>>>>> drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
>>>
>>> Tiezhu, this looks like a loongarch GCC bug with asm goto, or am I
>>> confused? See analysis below.
>>
>> This is related with GCC optimization "-fshrink-wrap" which is default y
>> on LoongArch, use "-fno-shrink-wrap" can avoid such issues, like this:
>
> As I showed, it looks like an actual runtime bug, not an objtool false
> positive. Disabling it only for CONFIG_OBJTOOLonly wouldn't fix that.
Here are my thoughts:
(1) -fshrink-wrap
The prologue may perform a variety of target dependent tasks such
as saving callee-saved registers, saving the return address, etc.
On some targets some of these tasks may be independent of others
and thus may be shrink-wrapped separately. These independent tasks
are referred to as components and are handled generically by the
target independent parts of GCC.
The initialization is not done as frequently on execution paths
where this would unnecessary.
"-fshrink-wrap" is enabled by default at -O and higher, will emit
function prologues only before parts of the function that need it,
rather than at the top of the function.
https://gcc.gnu.org/onlinedocs/gccint/Shrink-wrapping-separate-components.html
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fshrink-wrap
There is a potential execution path with only using s0 and ra
(without using s1, s2, s3, etc): 2d58-->2d70-->2f88-->2e78-->2e84
0000000000002d58 <__i2c_transfer>:
2d58: 02fe8063 addi.d $sp, $sp, -96
2d5c: 29c14077 st.d $s0, $sp, 80
2d60: 29c16061 st.d $ra, $sp, 88
2d64: 28c0408c ld.d $t0, $a0, 16
2d68: 00150097 or $s0, $a0, $zero
2d6c: 2600018c ldptr.d $t0, $t0, 0
2d70: 40021980 beqz $t0, 536 # 2f88
<.LVL1023>
...
0000000000002f88 <.LVL1023>:
2f88: 1a000006 pcalau12i $a2, 0
0000000000002f8c <.LVL1024>:
2f8c: 1a000004 pcalau12i $a0, 0
0000000000002f90 <.LVL1025>:
2f90: 02c00084 addi.d $a0, $a0, 0
2f94: 02c1c2e5 addi.d $a1, $s0, 112
0000000000002f98 <.LVL1026>:
2f98: 02c000c6 addi.d $a2, $a2, 0
2f9c: 54000000 bl 0 # 2f9c
<.LVL1026+0x4>
>
0000000000002fa0 <.LVL1027>:
2fa0: 02be8404 addi.w $a0, $zero, -95
2fa4: 53fed7ff b -300 # 2e78 <.L845>
...
0000000000002e78 <.L845>:
2e78: 28c16061 ld.d $ra, $sp, 88
2e7c: 28c14077 ld.d $s0, $sp, 80
0000000000002e80 <.LVL994>:
2e80: 02c18063 addi.d $sp, $sp, 96
2e84: 4c000020 jirl $zero, $ra, 0
From this point of view, it seems that there is no problem for the
generated instructions of the current code, it is not a runtime bug,
just a GCC optimization.
(2) Analysis
In fact, the generated objtool warning is because the break instruction
(2ee8) which is before the restoring s1 instruction (2eec) is annotated
as dead end.
0000000000002d58 <__i2c_transfer>:
2d58: 02fe8063 addi.d $sp, $sp, -96
2d5c: 29c14077 st.d $s0, $sp, 80
2d60: 29c16061 st.d $ra, $sp, 88
2d64: 28c0408c ld.d $t0, $a0, 16
2d68: 00150097 or $s0, $a0, $zero
2d6c: 2600018c ldptr.d $t0, $t0, 0
2d70: 40021980 beqz $t0, 536 # 2f88
<.LVL1023>
2d74: 29c12078 st.d $s1, $sp, 72
2d78: 001500b8 or $s1, $a1, $zero
0000000000002d7c <.LBB2114>:
2d7c: 400150a0 beqz $a1, 336 # 2ecc
<.LVL999+0x4>
...
2ecc: 1a000004 pcalau12i $a0, 0
0000000000002ed0 <.LVL1000>:
2ed0: 02c00084 addi.d $a0, $a0, 0
2ed4: 02c5a084 addi.d $a0, $a0, 360
2ed8: 54000000 bl 0 # 2ed8
<.LVL1000+0x8>
0000000000002edc <.LVL1001>:
2edc: 0015008c or $t0, $a0, $zero
2ee0: 02bfa804 addi.w $a0, $zero, -22
2ee4: 44003d80 bnez $t0, 60 # 2f20
<.LVL1008+0x8>
0000000000002ee8 <.L10001^B7>:
2ee8: 002a0001 break 0x1
2eec: 28c12078 ld.d $s1, $sp, 72
0000000000002ef0 <.LVL1002>:
2ef0: 53ff8bff b -120 # 2e78 <.L845>
This issue is introduced by the following changes:
#define __WARN_FLAGS(flags) \
do { \
instrumentation_begin(); \
- __BUG_FLAGS(BUGFLAG_WARNING|(flags), ANNOTATE_REACHABLE(10001b));\
+ if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
+ __BUG_FLAGS(BUGFLAG_WARNING|(flags), ANNOTATE_REACHABLE(10001b));\
instrumentation_end(); \
} while (0)
of commit e61a8b4b0d83 ("loongarch: add support for suppressing warning
backtraces") in the linux-next.git.
(3) -fno-shrink-wrap
"-fno-shrink-wrap" will save callee-saved registers and the return
address together as a whole block in the prologue at the top of the
function, and also restores them together as a whole block in the
epilogue.
0000000000002b38 <__i2c_transfer>:
2b38: 02fe8063 addi.d $sp, $sp, -96
2b3c: 29c14077 st.d $s0, $sp, 80
2b40: 29c12078 st.d $s1, $sp, 72
2b44: 29c10079 st.d $s2, $sp, 64
2b48: 29c16061 st.d $ra, $sp, 88
2b4c: 29c0e07a st.d $s3, $sp, 56
2b50: 29c0c07b st.d $s4, $sp, 48
2b54: 29c0a07c st.d $s5, $sp, 40
2b58: 29c0807d st.d $s6, $sp, 32
2b5c: 29c0607e st.d $s7, $sp, 24
2b60: 29c0407f st.d $s8, $sp, 16
...
0000000000002c38 <.L747>:
2c38: 28c16061 ld.d $ra, $sp, 88
2c3c: 28c14077 ld.d $s0, $sp, 80
0000000000002c40 <.LVL937>:
2c40: 28c12078 ld.d $s1, $sp, 72
2c44: 28c10079 ld.d $s2, $sp, 64
0000000000002c48 <.LVL938>:
2c48: 28c0e07a ld.d $s3, $sp, 56
2c4c: 28c0c07b ld.d $s4, $sp, 48
2c50: 28c0a07c ld.d $s5, $sp, 40
2c54: 28c0807d ld.d $s6, $sp, 32
2c58: 28c0607e ld.d $s7, $sp, 24
2c5c: 28c0407f ld.d $s8, $sp, 16
2c60: 02c18063 addi.d $sp, $sp, 96
2c64: 4c000020 jirl $zero, $ra, 0
(4) Solution 1
One way is to annotate __BUG_ENTRY() as reachable whether
KUNIT_IS_SUPPRESSED_WARNING() is true or false, like this:
---8<---
diff --git a/arch/loongarch/include/asm/bug.h
b/arch/loongarch/include/asm/bug.h
index b79ff6696ce6..e41ebeaba204 100644
--- a/arch/loongarch/include/asm/bug.h
+++ b/arch/loongarch/include/asm/bug.h
@@ -60,8 +60,9 @@
#define __WARN_FLAGS(flags) \
do { \
instrumentation_begin(); \
- if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
- __BUG_FLAGS(BUGFLAG_WARNING|(flags),
ANNOTATE_REACHABLE(10001b));\
+ if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
+ __BUG_FLAGS(BUGFLAG_WARNING|(flags), ""); \
+ __BUG_FLAGS(0, ANNOTATE_REACHABLE(10001b)); \
instrumentation_end(); \
} while (0)
(5) Solution 2
The other way is to use "-fno-shrink-wrap" to aovid such issue under
CONFIG_OBJTOOL at compile-time, like this:
---8<---
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index 0304eabbe606..2d5529322357 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -106,6 +106,7 @@ KBUILD_CFLAGS +=
-mannotate-tablejump
else
KBUILD_CFLAGS += -fno-jump-tables # keep
compatibility with older compilers
endif
+KBUILD_CFLAGS += -fno-shrink-wrap
endif
KBUILD_RUSTFLAGS +=
--target=loongarch64-unknown-none-softfloat -Ccode-model=small
If you have more suggestion, please let me know.
Thanks,
Tiezhu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-07 10:52 ` Tiezhu Yang
@ 2025-04-08 1:23 ` Josh Poimboeuf
2025-04-08 2:45 ` Tiezhu Yang
0 siblings, 1 reply; 11+ messages in thread
From: Josh Poimboeuf @ 2025-04-08 1:23 UTC (permalink / raw)
To: Tiezhu Yang
Cc: Philip Li, kernel test robot, Guenter Roeck, oe-kbuild-all,
Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On Mon, Apr 07, 2025 at 06:52:10PM +0800, Tiezhu Yang wrote:
> There is a potential execution path with only using s0 and ra
> (without using s1, s2, s3, etc): 2d58-->2d70-->2f88-->2e78-->2e84
[...]
> From this point of view, it seems that there is no problem for the
> generated instructions of the current code, it is not a runtime bug,
> just a GCC optimization.
I don't see how this is responsive to my email.
I described a code path which revealed a GCC bug, specifically with asm
goto (unless I got something wrong). Then you responded with a
*completely different* code path.
How does that prove my original code path isn't possible?
To summarize, the path I found was
2d58 ... 2d9c -> 2da8 .. 2dc4 -> 2ebc .. 2ec0 (runtime patched static branch) -> 2e78 .. 2e84 (ret)
> (2) Analysis
>
> In fact, the generated objtool warning is because the break instruction
> (2ee8) which is before the restoring s1 instruction (2eec) is annotated
> as dead end.
Actually, it's the opposite. Objtool would normally consider BREAK to
be a dead end. But it's annotated as "reachable", aka "non dead end".
> This issue is introduced by the following changes:
>
> #define __WARN_FLAGS(flags) \
> do { \
> instrumentation_begin(); \
> - __BUG_FLAGS(BUGFLAG_WARNING|(flags), ANNOTATE_REACHABLE(10001b));\
> + if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
> + __BUG_FLAGS(BUGFLAG_WARNING|(flags), ANNOTATE_REACHABLE(10001b));\
> instrumentation_end(); \
> } while (0)
>
> of commit e61a8b4b0d83 ("loongarch: add support for suppressing warning
> backtraces") in the linux-next.git.
Putting that annotation behind a conditional should not break anything.
> (4) Solution 1
> One way is to annotate __BUG_ENTRY() as reachable whether
> KUNIT_IS_SUPPRESSED_WARNING() is true or false, like this:
>
> ---8<---
> diff --git a/arch/loongarch/include/asm/bug.h
> b/arch/loongarch/include/asm/bug.h
> index b79ff6696ce6..e41ebeaba204 100644
> --- a/arch/loongarch/include/asm/bug.h
> +++ b/arch/loongarch/include/asm/bug.h
> @@ -60,8 +60,9 @@
> #define __WARN_FLAGS(flags) \
> do { \
> instrumentation_begin(); \
> - if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
> - __BUG_FLAGS(BUGFLAG_WARNING|(flags),
> ANNOTATE_REACHABLE(10001b));\
> + if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
> + __BUG_FLAGS(BUGFLAG_WARNING|(flags), ""); \
> + __BUG_FLAGS(0, ANNOTATE_REACHABLE(10001b)); \
> instrumentation_end(); \
> } while (0)
Huh? That's basically:
if (!suppress_warning)
WARN();
BUG();
So it upgrades a conditional WARN to an unconditional BUG???
Not to mention the reachable annotations are backwards: the WARN() is
annotated as dead end while the BUG() is annotated reachable.
Even if that silences objtool somehow, it will most definitely have the
wrong runtime behavior.
> (5) Solution 2
> The other way is to use "-fno-shrink-wrap" to aovid such issue under
> CONFIG_OBJTOOL at compile-time, like this:
As far as I can tell, that would be a workaround to get objtool to stop
warning about a legitimate compiler bug.
--
Josh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-08 1:23 ` Josh Poimboeuf
@ 2025-04-08 2:45 ` Tiezhu Yang
2025-04-08 6:29 ` Josh Poimboeuf
0 siblings, 1 reply; 11+ messages in thread
From: Tiezhu Yang @ 2025-04-08 2:45 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Philip Li, kernel test robot, Guenter Roeck, oe-kbuild-all,
Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On 04/08/2025 09:23 AM, Josh Poimboeuf wrote:
> On Mon, Apr 07, 2025 at 06:52:10PM +0800, Tiezhu Yang wrote:
>> There is a potential execution path with only using s0 and ra
>> (without using s1, s2, s3, etc): 2d58-->2d70-->2f88-->2e78-->2e84
>
> [...]
>
>> From this point of view, it seems that there is no problem for the
>> generated instructions of the current code, it is not a runtime bug,
>> just a GCC optimization.
>
> I don't see how this is responsive to my email.
>
> I described a code path which revealed a GCC bug, specifically with asm
> goto (unless I got something wrong). Then you responded with a
> *completely different* code path.
>
> How does that prove my original code path isn't possible?
>
> To summarize, the path I found was
>
> 2d58 ... 2d9c -> 2da8 .. 2dc4 -> 2ebc .. 2ec0 (runtime patched static branch) -> 2e78 .. 2e84 (ret)
Sorry, you are right, I misunderstood.
>> (2) Analysis
>>
>> In fact, the generated objtool warning is because the break instruction
>> (2ee8) which is before the restoring s1 instruction (2eec) is annotated
>> as dead end.
>
> Actually, it's the opposite. Objtool would normally consider BREAK to
> be a dead end. But it's annotated as "reachable", aka "non dead end".
>
>> This issue is introduced by the following changes:
>>
>> #define __WARN_FLAGS(flags) \
>> do { \
>> instrumentation_begin(); \
>> - __BUG_FLAGS(BUGFLAG_WARNING|(flags), ANNOTATE_REACHABLE(10001b));\
>> + if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
>> + __BUG_FLAGS(BUGFLAG_WARNING|(flags), ANNOTATE_REACHABLE(10001b));\
>> instrumentation_end(); \
>> } while (0)
>>
>> of commit e61a8b4b0d83 ("loongarch: add support for suppressing warning
>> backtraces") in the linux-next.git.
>
> Putting that annotation behind a conditional should not break anything.
OK, got it.
>> (4) Solution 1
>> One way is to annotate __BUG_ENTRY() as reachable whether
>> KUNIT_IS_SUPPRESSED_WARNING() is true or false, like this:
>>
>> ---8<---
>> diff --git a/arch/loongarch/include/asm/bug.h
>> b/arch/loongarch/include/asm/bug.h
>> index b79ff6696ce6..e41ebeaba204 100644
>> --- a/arch/loongarch/include/asm/bug.h
>> +++ b/arch/loongarch/include/asm/bug.h
>> @@ -60,8 +60,9 @@
>> #define __WARN_FLAGS(flags) \
>> do { \
>> instrumentation_begin(); \
>> - if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
>> - __BUG_FLAGS(BUGFLAG_WARNING|(flags),
>> ANNOTATE_REACHABLE(10001b));\
>> + if (!KUNIT_IS_SUPPRESSED_WARNING(__func__)) \
>> + __BUG_FLAGS(BUGFLAG_WARNING|(flags), ""); \
>> + __BUG_FLAGS(0, ANNOTATE_REACHABLE(10001b)); \
>> instrumentation_end(); \
>> } while (0)
>
> Huh? That's basically:
>
> if (!suppress_warning)
> WARN();
> BUG();
>
> So it upgrades a conditional WARN to an unconditional BUG???
>
> Not to mention the reachable annotations are backwards: the WARN() is
> annotated as dead end while the BUG() is annotated reachable.
>
> Even if that silences objtool somehow, it will most definitely have the
> wrong runtime behavior.
Yes, my original analysis seems wrong.
>> (5) Solution 2
>> The other way is to use "-fno-shrink-wrap" to aovid such issue under
>> CONFIG_OBJTOOL at compile-time, like this:
>
> As far as I can tell, that would be a workaround to get objtool to stop
> warning about a legitimate compiler bug.
So this is a run-time bug rather than a compile-time warning, it should
put the option "-fno-shrink-wrap" outside CONFIG_OBJTOOL in
arch/loongarch/Makefile as a workaround, like this:
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index 0304eabbe606..98241e3015fb 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -108,6 +108,8 @@ KBUILD_CFLAGS +=
-fno-jump-tables # keep compatibility with older compilers
endif
endif
+KBUILD_CFLAGS += -fno-shrink-wrap
+
KBUILD_RUSTFLAGS +=
--target=loongarch64-unknown-none-softfloat -Ccode-model=small
KBUILD_RUSTFLAGS_KERNEL +=
-Zdirect-access-external-data=yes
KBUILD_RUSTFLAGS_MODULE += -Zdirect-access-external-data=no
Thanks,
Tiezhu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-08 2:45 ` Tiezhu Yang
@ 2025-04-08 6:29 ` Josh Poimboeuf
2025-04-08 9:32 ` Tiezhu Yang
0 siblings, 1 reply; 11+ messages in thread
From: Josh Poimboeuf @ 2025-04-08 6:29 UTC (permalink / raw)
To: Tiezhu Yang
Cc: Philip Li, kernel test robot, Guenter Roeck, oe-kbuild-all,
Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On Tue, Apr 08, 2025 at 10:45:51AM +0800, Tiezhu Yang wrote:
> So this is a run-time bug rather than a compile-time warning, it should
> put the option "-fno-shrink-wrap" outside CONFIG_OBJTOOL in
> arch/loongarch/Makefile as a workaround, like this:
If loongarch folks agree it's a compiler bug, it should be reported to
GCC, so the issue is better understood (and can get fixed).
Without understanding the root cause, we don't know if -fno-shrink-wrap
fixes it, or just makes this particular occurrence go away.
--
Josh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24
2025-04-08 6:29 ` Josh Poimboeuf
@ 2025-04-08 9:32 ` Tiezhu Yang
0 siblings, 0 replies; 11+ messages in thread
From: Tiezhu Yang @ 2025-04-08 9:32 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Philip Li, kernel test robot, Guenter Roeck, oe-kbuild-all,
Andrew Morton, Linux Memory Management List,
Alessandro Carminati, Peter Zijlstra, linux-kernel, loongarch
On 04/08/2025 02:29 PM, Josh Poimboeuf wrote:
> On Tue, Apr 08, 2025 at 10:45:51AM +0800, Tiezhu Yang wrote:
>> So this is a run-time bug rather than a compile-time warning, it should
>> put the option "-fno-shrink-wrap" outside CONFIG_OBJTOOL in
>> arch/loongarch/Makefile as a workaround, like this:
>
> If loongarch folks agree it's a compiler bug, it should be reported to
> GCC, so the issue is better understood (and can get fixed).
>
> Without understanding the root cause, we don't know if -fno-shrink-wrap
> fixes it, or just makes this particular occurrence go away.
OK, thank you. I have discussed offline with the developers
Rui Wang and Lulu Cheng who are familiar with compiler, the
root cause may be that if a jump label's control flow path
exactly matches the caller's epilogue, the compiler may omit
restoring saved registers, it needs to be confirmed by GCC
developers.
By the way, add an empty inline assembly can also work around
the problem, like this:
diff --git a/arch/loongarch/include/asm/jump_label.h
b/arch/loongarch/include/asm/jump_label.h
index 8a924bd69d19..dbc105e62380 100644
--- a/arch/loongarch/include/asm/jump_label.h
+++ b/arch/loongarch/include/asm/jump_label.h
@@ -34,6 +34,7 @@ static __always_inline bool arch_static_branch(struct
static_key * const key, co
return false;
l_yes:
+ asm volatile("");
return true;
}
@@ -47,6 +48,7 @@ static __always_inline bool
arch_static_branch_jump(struct static_key * const ke
return false;
l_yes:
+ asm volatile("");
return true;
}
We will fix this issue once the root cause is clear.
Thanks,
Tiezhu
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-04-08 9:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-04-01 2:44 [linux-next:master 12681/13861] drivers/i2c/i2c-core-base.o: warning: objtool: __i2c_transfer+0x120: stack state mismatch: reg1[24]=-1+0 reg2[24]=-2-24 kernel test robot
2025-04-01 4:38 ` Philip Li
2025-04-01 19:45 ` Josh Poimboeuf
2025-04-03 9:35 ` Tiezhu Yang
2025-04-03 9:40 ` Huacai Chen
2025-04-03 14:37 ` Josh Poimboeuf
2025-04-07 10:52 ` Tiezhu Yang
2025-04-08 1:23 ` Josh Poimboeuf
2025-04-08 2:45 ` Tiezhu Yang
2025-04-08 6:29 ` Josh Poimboeuf
2025-04-08 9:32 ` Tiezhu Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox