Comment # 7 on bug 1092456 from Michal Kube��ek

(In reply to Jessica Yu from comment #6)
> Another thought: is it possible that the config with which the module(s)
> were compiled differs slightly from that of the running kernel (while
> controlling for kernel version)? That may potentially produce a differently
> sized module struct whose fields could have slightly different offsets..

Looks like you are right. I checked the layout of struct module in vmlinux
and compiled module (compiled on SLE15 but that shouldn't make a difference)
and indeed, they differ:

--- m2.vmlinux  2018-05-14 06:15:09.710000000 -0400
+++ m2.module   2018-05-14 06:13:39.130000000 -0400
@@ -168,8 +168,9 @@
 /*           |     4 */    unsigned int percpu_size;
 /*           |     4 */    unsigned int num_tracepoints;
 /*           |     8 */    struct tracepoint * const *tracepoints_ptrs;
+/*           |     8 */    struct jump_entry *jump_entries;
+/*           |     4 */    unsigned int num_jump_entries;
 /*           |     4 */    unsigned int num_trace_bprintk_fmt;
-/* XXX  4-byte hole  */
 /*           |     8 */    const char **trace_bprintk_fmt_start;
 /*           |     8 */    struct trace_event_call **trace_events;
 /*           |     4 */    unsigned int num_trace_events;

As a result, the module thinks module::refcnt should be at offset 808 while
kernel expects it at offset 800. module's structure has module::exit at offset
800 and the numbers shown in comments 0 and 5 could pretty well be lower
32 bits of these callbacks.

The two extra members in module's version indicate a HAVE_JUMP_LABEL was
enabled when building the module but not kernel so the next question is where
does this difference come from.