[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

linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed

* [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