Re: linux-next: Tree for Dec 6 (objtool, lots in btrfs)

[Josh Poimboeuf]

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.

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
 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__))