From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10146C36010 for ; Tue, 8 Apr 2025 01:23:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9478D6B0030; Mon, 7 Apr 2025 21:23:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F5B36B0031; Mon, 7 Apr 2025 21:23:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BD256B0032; Mon, 7 Apr 2025 21:23:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5D88F6B0030 for ; Mon, 7 Apr 2025 21:23:31 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 801B5C188D for ; Tue, 8 Apr 2025 01:23:31 +0000 (UTC) X-FDA: 83309129022.15.46EB121 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf09.hostedemail.com (Postfix) with ESMTP id DD28B14000E for ; Tue, 8 Apr 2025 01:23:29 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=q0yuj3CX; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of jpoimboe@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=jpoimboe@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744075410; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j8Mqum+GOS3M32SROXvpUTZajf+Z6XKU5LACB718IbI=; b=lGrg9VK0750sJw5AA/vQluxfO+rwTbUAx7TMXnLYCQnvpDjcQUbu4aT+3zTugmEFRo5lgW woDSRfJezV85IGf2J4ehWwWL9PUzFaTmXoKp/Jy4d9Svb9LC4teoFuC2XcUEuFZ1wMJD92 sDnLVlwbMQwMLRpxckV7cA29Z/IHsBM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=q0yuj3CX; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of jpoimboe@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=jpoimboe@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744075410; a=rsa-sha256; cv=none; b=QzYog9BGabHj2ttKH8q8teI/E+ExHTCWpYdi8OE8tZHTGw/XItIJGhdRgf5Z+tPjCCQyqX pm8Jau/a40h6F9v/lQWEDtFIUZiiw9ut/Bj1zb3m9lw391Gr0+nHSFvmdm9lmM6zY3FXcS w231V9zjCcUw2eXJUCISm9Wbi/2ZuL8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 68A30A47A7F; Tue, 8 Apr 2025 01:18:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5B0EC4CEDD; Tue, 8 Apr 2025 01:23:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744075408; bh=84fDVGkUTdJUTtSMGNxjTm2lp64cSjhR44AJkaIZClM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q0yuj3CXbsGBJDNquyi9xGT7PWLUg6Y+4Q0thl7hHk34amRW7RJeRPi4zHfN8zZDd ZG3xlqKO0SRlIkQFDoKBppvkRM5uR7JPP/cu1tEgVlmjFftT3mLQmRwibEzKHe9W90 MPJnaUG9KvLZHBgWl83z2uhGvKRN/H5rAUUqa59mJOn9N4T+M7TJoQqvwa0+YKgeMU UVxPdgktpgYceD15hp3fmVsMxUBHSdu7d/1PM5GhAKX6rpF9bzAlll89L/rArnyU+b LbHvcubwJ8Iv2yrWtYdApu6hLdScRuB3tmXX9S8JnP5DE+nzfvzmjUxdswjkTnFrdX ZUyH+CM/sj/1w== Date: Mon, 7 Apr 2025 18:23:25 -0700 From: Josh Poimboeuf To: Tiezhu Yang Cc: Philip Li , kernel test robot , Guenter Roeck , oe-kbuild-all@lists.linux.dev, Andrew Morton , Linux Memory Management List , Alessandro Carminati , Peter Zijlstra , 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 Message-ID: References: <202504011011.jyZ6NtXx-lkp@intel.com> <348cdb14-f8cf-1e7b-44b2-79dc4dda4e35@loongson.cn> <0cbe7ab8-bd87-b5f7-0513-07c82a7e76c9@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0cbe7ab8-bd87-b5f7-0513-07c82a7e76c9@loongson.cn> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DD28B14000E X-Stat-Signature: p8cutyao9unqxqfxe6icwgwoyb8rour8 X-Rspam-User: X-HE-Tag: 1744075409-893799 X-HE-Meta: U2FsdGVkX1+TXTRhL3nrSeWCBk9Ax9UwNkjc7083EyTQuN2V76ZumRjaw24314qjr7GqkqKfe9yhVyBx8ksuP83SQNHvQwcdZ/GG/VNDpVhN7hc1L4zkG9s8NhrgrGt44cqdhf9hOEKREnR7nuYYWB+Sc4RFHKvpULEr+2eM2EyC9djurFiEN4qvIsLAKAsYKLVyXd9my0i8IJB3mIjmJbZXT4QZfURUcN4kU8Otq4DkjvQEUBP9QLzX/KMlQ3de3Nwr83Z/NUMe/07NB/BtMR5Qd2BxxriKDgffSax/HuyO/yXowl6lOQxq0ujgVYRgVKciN28HngzEook8LzwIk9dhz3PbH29DM0rj5FHct8JHRrNexGqIKSep9qbyGZmfA0HEKH85JxW06EzRNhQ0A83ClmZdzETwstd+0NbSgB6r9Mjry2uv++XX1FmWTtDZhmXmIlGbEncg7gqLxMimTVZasP5xb8uwu02SV0cI8H+ugr9Je9UvLohEy9tFs0+VzQBUwiEv4WgOiY2LUnjdx77G3fbJDlNpq2if23aR36wY1eV7IGLdoDqksN5hxFhNprjjSnItAZ0KbF2F/daAUgexUBeBytU+wDckf7tXvA4w3ccWKopS6AuQ9gfF1XfOsyzoZaOYhkSqw2g4E00BckHH/FgMtPvsrgowImHsNR6cPlKiZZ724QubUfbNeB+qFQngtabBKNpQrltjKyIs/bn8azyDmXMN1ta5uhnrS3sQoWKhtebhCx8XyO1ucKtjRfMiTe46pc4AOPLV1toCkhZCJGSFQZeXIc/Av6m4ffZnzoTk4wd1mk4IHo50MHPmz4fclg1KMahTJblty+sowRvpSfPaAGz0+vTh9J5PGN3VAF/yektcn88gIRwkhdkfyvNsucvow8BuPTm13NQra5h+P+1MNy6EIJ0KLCafw2At68ZwBja+f9V3imnQUrQM5TCTNcaWDIzOLF81X0l D9kuMzuz QHUk3D7VSX1pXaoCK+j3AtZHeieH+NFis9WLznbPF811FpDLBkO1c+1B+EGsw0WRyjwYlrLI8J85kOTbwIeRhVcxDdc3xLMnfgvnrWvE0yGrn3b7pgYLmZasYSt1w1XArzhvpOi+uj1DRr+hkJKMcO16WqWfdjLc0fBXLhJ9gs6g4KOgjVnB4e1QiFbnDmbrPdB5G5qC/+1712B+l3f08brVbqcQk37zxT0kRdzB8G5sghIjJpBVnUXdPP8dL9lHQb/Ux/MQz+7QPKZO9ZQpEvVNXZ1NfUyXxIso9lUnVOaRWSIs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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