15

During the "make" step of the Linux kernel compilation I get lots of these errors:

Building modules, stage 2.
MODPOST 2283 modules
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

I know I can just do a make CONFIG_DEBUG_SECTION_MISMATCH=y and go ahead with it, but I want to know if there is any better way to handle this. Maybe reporting to someone or how I fix these problems myself, etc.

tshepang
  • 12,111
  • 21
  • 91
  • 136
user361697
  • 1,093
  • 2
  • 12
  • 21
  • 2
    `make CONFIG_DEBUG_SECTION_MISMATCH=y` took ~2h here to rebuild the whole kernel and modules, only to mention that some obscure eth and scsi drivers are doing odd things in their initialisation functions. – PypeBros Feb 15 '13 at 14:29

1 Answers1

29

This is just a warning. The kernel build systems did a sanity check and found out something that might be an error. The warning message says somewhere in kernel code there is code that might do inappropriate cross section access. Note that your kernel did build!

To understand what the warning means, consider the following example:

Some kernel code in the kernel text section might be trying to call a function marked with the __init data macro, which the linker puts in the kernel init section that gets de-allocated after boot or module loading.

This might be a run time error since if the code in the text section calls the code in the init section after the initialization code has finished, it is basically calling a stale pointer.

Having said that, that call may be perfectly fine - it is possible that the calls in the kernel text section has some good reason to know that it only calls the function in the init section when it is guaranteed to be there.

This, of course, is just an example. Similar other scenarios also exists.

The solution is to compile with CONFIG_DEBUG_SECTION_MISMATCH=y which will give you output of what function is trying to access which data or function and which section they belong to. You can then try to figure out if the build time warning is warranted and if so hopefully fix.

The init.h macros __ref and __refdata can be used to allow such init references without warnings. For example,

char * __init_refok bar(void) 
{
  static int flag = 0;
  static char* rval = NULL;
  if(!flag) {
     flag = 1;
     rval = init_fn(); /* a function discarded after init */
  }
  return rval;
}

__init_refok, etc can fix "valid" instances, so the fact they exist may not inspire confidence.

artless noise
  • 21,212
  • 6
  • 68
  • 105
gby
  • 14,900
  • 40
  • 57
  • The __init comment saved me a sleepless night for sure. Thank you. – Jiri Klouda Feb 08 '13 at 10:55
  • 1
    the kind of output you'll get: ""WARNING: drivers/net/ethernet/3com/3c509.o(.data+0x11c): Section mismatch in reference from the variable el3_eisa_driver to the function .init.text:el3_eisa_probe() The variable el3_eisa_driver references the function __init el3_eisa_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console"" – PypeBros Feb 15 '13 at 14:29