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
