From: Randy Dunlap <rdunlap@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: dsterba@suse.cz, Stephen Rothwell <sfr@canb.auug.org.au>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Btrfs <linux-btrfs@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: linux-next: Tree for Dec 6 (objtool, lots in btrfs)
Date: Fri, 13 Dec 2019 16:04:58 -0800 [thread overview]
Message-ID: <c6a33c21-3e71-ac98-cc95-db008764917c@infradead.org> (raw)
In-Reply-To: <20191213235054.6k2lcnwa63r26zwi@treble>
On 12/13/19 3:50 PM, Josh Poimboeuf wrote:
> On Fri, Dec 13, 2019 at 03:03:11PM -0800, Randy Dunlap wrote:
>> On 12/12/19 12:25 PM, Randy Dunlap wrote:
>>> On 12/12/19 10:47 AM, Josh Poimboeuf wrote:
>>>> On Wed, Dec 11, 2019 at 08:21:38AM -0800, Randy Dunlap wrote:
>>>>> [oops, forgot to add Josh and PeterZ]
>>>>>
>>>>> On 12/11/19 5:49 AM, David Sterba wrote:
>>>>>> On Fri, Dec 06, 2019 at 08:17:30AM -0800, Randy Dunlap wrote:
>>>>>>> On 12/5/19 6:54 PM, Stephen Rothwell wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Please do not add any material for v5.6 to your linux-next included
>>>>>>>> trees until after v5.5-rc1 has been released.
>>>>>>>>
>>>>>>>> Changes since 20191204:
>>>>>>>>
>>>>>>>
>>>>>>> on x86_64:
>>>>>>>
>>>>>>> fs/btrfs/ctree.o: warning: objtool: btrfs_search_slot()+0x2d4: unreachable instruction
>>>>>>
>>>>>> Can somebody enlighten me what is one supposed to do to address the
>>>>>> warnings? Function names reported in the list contain our ASSERT macro
>>>>>> that conditionally calls BUG() that I believe is what could cause the
>>>>>> unreachable instructions but I don't see how.
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/ctree.h#n3113
>>>>>>
>>>>>> __cold
>>>>>> static inline void assfail(const char *expr, const char *file, int line)
>>>>>> {
>>>>>> if (IS_ENABLED(CONFIG_BTRFS_ASSERT)) {
>>>>>> pr_err("assertion failed: %s, in %s:%d\n", expr, file, line);
>>>>>> BUG();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> #define ASSERT(expr) \
>>>>>> (likely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
>>>>>>
>>>>
>>>> Randy, can you share one of the btrfs .o files? I'm not able to
>>>> recreate.
>>>>
>>>
>>> Hm. I'll have to try to recreate this. I no longer have files from 20191206
>>> (lack of space).
>>>
>>> I'll let you know if/when I can recreate it.
>>
>> OK, 40 builds later, I have reproduced it.
>>
>> I am attaching one of the btrfs .o files and the kernel config file (FTR).
>> (gzipped)
>> Let me know if you want more of the .o files.
>
> Thanks. This is arguably a compiler bug, but the below produces better
> code generation by adding a noreturn annotation. I think GCC gets
> tripped up by the IS_ENABLED conditional and can't always tell that
> assfail (sic) doesn't return.
>
> BTW, I'm on my way out the door for a week of much-needed PTO but I can
> handle this patch (and several others I have pending which were reported
> by you) when I get back.
Sure, no hurry. Have a good one.
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index b2e8fd8a8e59..bbd68520f5f1 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -3110,14 +3110,16 @@ do { \
> rcu_read_unlock(); \
> } while (0)
>
> -__cold
> +#ifdef CONFIG_BTRFS_ASSERT
> +__cold __unlikely
what provides __unlikely? It is causing build errors.
and if I remove the "__unlikely", I still see the objtool warnings
(unreachable instructions).
> static inline void assfail(const char *expr, const char *file, int line)
> {
> - if (IS_ENABLED(CONFIG_BTRFS_ASSERT)) {
> - pr_err("assertion failed: %s, in %s:%d\n", expr, file, line);
> - BUG();
> - }
> + pr_err("assertion failed: %s, in %s:%d\n", expr, file, line);
> + BUG();
> }
> +#else
> +static inline void assfail(const char *expr, const char *file, int line) {}
> +#endif
>
> #define ASSERT(expr) \
> (likely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
>
--
~Randy
next prev parent reply other threads:[~2019-12-14 0:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 2:54 linux-next: Tree for Dec 6 Stephen Rothwell
2019-12-06 10:15 ` Geert Uytterhoeven
2019-12-06 12:43 ` Stephen Rothwell
2019-12-06 16:17 ` linux-next: Tree for Dec 6 (objtool, lots in btrfs) Randy Dunlap
2019-12-11 13:49 ` David Sterba
2019-12-11 16:21 ` Randy Dunlap
2019-12-12 18:47 ` Josh Poimboeuf
2019-12-12 20:25 ` Randy Dunlap
2019-12-13 23:03 ` Randy Dunlap
2019-12-13 23:50 ` Josh Poimboeuf
2019-12-14 0:04 ` Randy Dunlap [this message]
2019-12-14 5:45 ` Josh Poimboeuf
2019-12-14 7:05 ` Randy Dunlap
2019-12-17 15:25 ` David Sterba
2020-01-17 17:26 ` Josh Poimboeuf
2020-01-17 20:28 ` Marco Elver
2020-01-17 21:26 ` Josh Poimboeuf
2020-01-17 22:22 ` Josh Poimboeuf
2019-12-17 15:29 ` David Sterba
2020-01-10 19:46 ` David Sterba
2020-01-17 15:28 ` Josh Poimboeuf
2020-01-17 16:50 ` David Sterba
2020-01-17 17:03 ` Josh Poimboeuf
2020-01-20 15:52 ` Josh Poimboeuf
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=c6a33c21-3e71-ac98-cc95-db008764917c@infradead.org \
--to=rdunlap@infradead.org \
--cc=dsterba@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
/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;
as well as URLs for NNTP newsgroup(s).