objtool: unreachable instruction warning

[arndb]

Nine files in the kernel trigger an 'unreachable instruction warning' from objtool:

arch/x86/entry/entry_64.o: warning: objtool: .entry.text+0xaa0: unreachable instruction drivers/hwmon/pmbus/adm1275.o: warning: objtool: adm1275_probe()+0x5c8: unreachable instruction drivers/scsi/smartpqi/smartpqi_init.o: warning: objtool: pqi_shutdown()+0x377: unreachable instruction drivers/xen/privcmd.o: warning: objtool: privcmd_ioctl_mmap_batch()+0x58c: unreachable instruction fs/btrfs/extent-tree.o: warning: objtool: btrfs_issue_discard()+0x281: unreachable instruction kernel/sched/deadline.o: warning: objtool: sched_dl_overflow()+0x687: unreachable instruction lib/string.o: warning: objtool: fortify_panic()+0x3: unreachable instruction net/mac80211/tdls.o: warning: objtool: ieee80211_tdls_mgmt()+0x3f2: unreachable instruction net/xfrm/xfrm_output.o: warning: objtool: xfrm_outer_mode_output()+0x106: unreachable instruction

0x88D80D78-config.gz 0xEBF06C78-config.gz

[nickdesaulniers]

Detangling the 2 configs from the 9 object files, here's what I can reproduce:

0x88D80D78-config.gz:

1. drivers/hwmon/pmbus/adm1275.o
2. drivers/xen/privcmd.o

0xEBF06C78-config.gz:

1. fs/btrfs/extent-tree.o

This was tested by:

$ wget <config above>
$ gunzip <config file compressed>
$ cp <config file compressed> .config
$ make LLVM=1 LLVM_IAS=1 -j72 olddefconfig
$ make LLVM=1 LLVM_IAS=1 -j72 <reported object file>

This is with linux @ e359bce39d9085ab24eaa0bb0778bb5f6894144a and llvm @ ea8416bf4df4e2823d85d50d8ddd69dd8ed54720.

Of the above KCFLAGS="-mllvm -trap-unreachable" was able to resolve drivers/hwmon/pmbus/adm1275.o. adm1275_probe does contain a switch statement, so this is likely #621.

For drivers/xen/privcmd.o,

drivers/xen/privcmd.o: warning: objtool: mmap_batch_fn()+0x14c: unreachable instruction

creduce spits out a pretty big reproducer, but it seems to be some uses of __builtin_unreachable in mmap_batch_fn perhaps via the BUG_ON calls to BUG in arch/x86/include/asm/bug.h. If I comment out these two, I can build without error:

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 720a7b7abd46..308ef2a8b481 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -343,7 +343,7 @@ static int mmap_batch_fn(void *data, int nr, void *state)
        if (xen_feature(XENFEAT_auto_translated_physmap))
                cur_pages = &pages[st->index];

-       BUG_ON(nr < 0);
+       /*BUG_ON(nr < 0);*/
        ret = xen_remap_domain_gfn_array(st->vma, st->va & PAGE_MASK, gfnp, nr,
                                         (int *)gfnp, st->vma->vm_page_prot,
                                         st->domain, cur_pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 39a5580f8feb..e3bf844eea3d 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -144,7 +144,7 @@ static inline int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
         * and the consequences later is quite hard to detect what the actual
         * cause of "wrong memory was mapped in".
         */
-       BUG_ON(err_ptr == NULL);
+       //BUG_ON(err_ptr == NULL);
        return xen_remap_pfn(vma, addr, gfn, nr, err_ptr, prot, domid,
                             false, pages);

I wonder if those conditions somehow are true, due to optimizations for this given config?

TODO: check fs/btrfs/extent-tree.o

[nickdesaulniers]

The remaining issue above in xen BUG_ON might be a duplicate either #1563 or #1483. I haven't retested yet with either of those two fixes.