linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tiezhu Yang <yangtiezhu@loongson.cn>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Philip Li <philip.li@intel.com>,
	kernel test robot <lkp@intel.com>,
	Guenter Roeck <linux@roeck-us.net>,
	oe-kbuild-all@lists.linux.dev,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Alessandro Carminati <acarmina@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, loongarch@lists.linux.dev
Subject: 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
Date: Tue, 8 Apr 2025 10:45:51 +0800	[thread overview]
Message-ID: <5f830e7a-7cfa-3c62-ba3f-f93808e95821@loongson.cn> (raw)
In-Reply-To: <bzy7cad37tafrbcmsstn355fpljxxmi25ifc4piihp6ln3ztxh@zp3c7ydsjmuq>

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



  reply	other threads:[~2025-04-08  2:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01  2:44 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 [this message]
2025-04-08  6:29               ` Josh Poimboeuf
2025-04-08  9:32                 ` Tiezhu Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5f830e7a-7cfa-3c62-ba3f-f93808e95821@loongson.cn \
    --to=yangtiezhu@loongson.cn \
    --cc=acarmina@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --cc=lkp@intel.com \
    --cc=loongarch@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=philip.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox