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
next prev parent 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