Jiri Benc <jbenc@suse.cz> reported that modpost would stop with SIGABRT if
used with long filepaths.
The error looked like:
> Building modules, stage 2.
> MODPOST
> *** glibc detected *** scripts/mod/modpost: realloc(): invalid next size:
+0x0809f588 ***
> [...]
Fix this by allocating at least the required memory + SZ bytes each time.
Before we sometimes ended up allocating too little memory resuting in the
glibc detected bug above. Based on patch originally submitted by: Jiri
Benc <jbenc@suse.cz>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The scripts/genksyms/genksyms.c uses hardcoded "__crc_" prefix for
crc symbols in kernel and modules. The prefix should be replaced by
"MODULE_SYMBOL_PREFIX##__crc_" otherwise there will be warnings when
MODULE_SYMBOL_PREFIX is not NULL.
I am sorry my last patch for this issue is actually wrong. I revert
it in this patch.
Signed-off-by: Luke Yang <luke.adi@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Fix matching of devmodel in modaliases. It breaks automatic loading of any
dasd module.
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Warning now looks like this:
WARNING: vmlinux: 'strcpy' exported twice. Previous export was in vmlinux
Which gives much better hint how to fix it.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
When searching for symbols the only check performed was if
offset equals st_value. Adding an additional check to see if st_name
points t a valid name made us sort out a few more false positives and
let us report more correct names in warnings.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Building an allmodconfig kernel for ppc64 revealed a number of false
positives - originally reported by Andrew Morton.
This patch removes most if not all false positives for ppc64:
Section .opd
The .opd section contains function descriptors at least for ppc64.
So ignore it for .init.text (was ignored for .exit.text).
See description of function descriptors here:
http://www.linuxbase.org/spec/ELF/ppc64/PPC-elf64abi-1.7.html
Section .toc1
ppc64 places some static variables in .toc1 - ignore the.
Section __bug_tabe
BUG() and friends uses __bug_table. Ignore warnings from that section.
Module parameters are placed in .data.rel for ppc64, for adjust pattern to
match on section named .data*
Tested with gcc: 3.4.0 and binutils 2.15.90.0.3
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
In several cases the section mismatch check triggered false warnings.
Following patch introduce a whitelist to 'false positives' are not warned of.
Two types of patterns are recognised:
1) Typical case when a module parameter is _initdata
2) When a function pointer is assigned to a driver structure
In both patterns we rely on the actual name of the variable assigned
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
It seems popular to protect your work with copyright, so I decided to do
so for modpost which I patch a great deal atm.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Andrew Morton reported a number of false positives for ia64 - like these:
WARNING: drivers/acpi/button.o - Section mismatch: reference to .init.text: from .IA_64.unwind.init.text after '' (at offset 0x0)
WARNING: drivers/acpi/button.o - Section mismatch: reference to .exit.text: from .IA_64.unwind.exit.text after '' (at offset 0x0)
WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.text: from .IA_64.unwind after '' (at offset 0x1e8)
They are all false positives - or at least the .c code looks OK.
It is not known why sometimes a section name is appended and sometimes not.
Fix is to accept references from all sections that includes "unwind." in the name.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The kernel now requires that CC be 3.1.0 or higher. But we shouldn't place
that requirement upon HOSTCC unless we really need to. Fixes my ia64 problem.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Do not try to look up section name until we know it is not a special
section. Otherwise we will address outside legal space and segfault.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
A combination of calling modpost with option -a and MODVERDIR undefined
caused segmentation fault. So provide a default value and accept the
error messages it generates instead.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Section mismatch is identified as references to .init*
sections from non .init sections. And likewise references
to .exit.* sections outside .exit sections.
.init.* sections are discarded after a module is initialized
and references to .init.* sections are oops candidates.
.exit.* sections are discarded when a module is built-in and
thus references to .exit are also oops candidates.
The checks were possible to do using 'make buildcheck' which
called the two perl scripts: reference_discarded.pl and
reference_init.pl. This patch just moves the same functionality
inside modpost and the scripts are then obsoleted.
They will though be kept for a while so users can do double
checks - but note that some .o files are skipped by the perl scripts
so result is not 1:1.
All credit for the concept goes to Keith Owens who implemented
the original perl scrips - this patch just moves it to modpost.
Compared to the perl script the implmentation in modpost will be run
for each kernel build - thus catching the error much sooner, but
the downside is that the individual .o file are not always identified.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
In modpost introduce a check for symbols exported twice.
This check caught only one victim (inet_bind_bucket_create) for
which a patch is already sent to netdev.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
With following patch a second option is enabled to obtain
symbol information from a second external module when a
external module is build.
The recommended approach is to use a common kbuild file but
that may be impractical in certain cases.
With this patch one can copy over a Module.symvers from one
external module to make symbols (and symbol versions) available
for another external module.
Updated documentation in Documentation/kbuild/modules.txt
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Here's the patch for modalias support for input classes. It uses
comma-separated numbers, and doesn't describe all the potential keys (no
module currently cares, and that would make the strings huge). The
changes to input.h are to move the definitions needed by file2alias
outside __KERNEL__. I chose not to move those definitions to
mod_devicetable.h, because there are so many that it might break compile
of something else in the kernel.
The rest is fairly straightforward.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
CC: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a problem when we use well known kernel symbols as module
names.
For example, if module source name is current.c, idle_stack.c or etc.,
we have a bad KBUILD_MODNAME value.
For example, KBUILD_MODNAME will be "get_current()" instead of "current", or
"(init_thread_union.stack)" instead of "idle_task".
The trick is to define a stringify macro on the commandline - named
KBUILD_STR for namespace reasons - and then to stringify the module
name.
There are a few uses of KBUILD_MODNAME throughout the tree but the usage
is for debug and will not be harmed by this change so left untouched for now.
While at it KBUILD_BASENAME was changed too. Any spinlock usage in the
unix module would have created wrong section names without it.
Usage in spinlock.h fixed so it no longer stringify KBUILD_BASENAME.
Original patch from Ustyogov Roman - all bugs introduced by me.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This is the patch for the following issue:
In include/linux/module.h, "__crc_" and "__ksymtab_" are hard
coded to be the prefix for some kinds of symbols (CRC symbol and
ksymtab section). But in script /mod/modpost.c,
MODULE_SYMBOL_PREFIX##"__crc_" is used as the prefix to search CRC
symbols. So if an architecture (such as h8300 or Blackfin) defines
MODULE_SYMBOL_PREFIX as not NULL ("_"), modpost will always warn about
"no invalid crc".
And it is the same with KSYMTAB_PFX.
Signed-off-by: Luke Yang <luke.adi@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This still leaves driver and architecture-specific subdirectories alone,
but gets rid of the bulk of the "generic" generated files that we should
ignore.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- Added a missing TO_NATIVE call to scripts/mod/file2alias.c:do_pcmcia_entry()
- Add an alignment attribute to struct pcmcia_device_no to solve an alignment
issue seen when cross-compiling on x86 for m68k.
Signed-off-by: Kars de Jong <jongk@linux-m68k.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
From: Al Viro <viro@ZenIV.linux.org.uk>
Instead of playing all of these hand-coded assembler aliasing games,
just translate symbol names in the name space ".sym" to "_Sym" at
module load time.
Signed-off-by: David S. Miller <davem@davemloft.net>
GLIBC 2.3.4 and later changed the STT_REGISTER macro to
STT_SPARC_REGISTER, so we need to cope with that somehow.
Original patch from fabbione, reposted by Ben Collins.
Signed-off-by: David S. Miller <davem@davemloft.net>
Recently a change in the glibc elf.h header has been introduced causing
modpost to spawn tons of warnings (like the one below) building the kernel
on sparc:
[SNIP]
*** Warning: "current_thread_info_reg" [net/sunrpc/auth_gss/auth_rpcgss.ko] undefined!
*** Warning: "" [net/sunrpc/auth_gss/auth_rpcgss.ko] undefined!
*** Warning: "" [net/sunrpc/auth_gss/auth_rpcgss.ko] undefined!
[SNIP]
Ben Collins discovered that the STT_REGISTERED definition in glibc did change
and that this change needs to be propagated to modpost.
glibc change:
-#define STT_REGISTER 13 /* Global register reserved to app. */
+#define STT_SPARC_REGISTER 13 /* Global register reserved to app. */
I did and tested this simple patch to maintain compatibility with newer (>= 2.3.4)
and older (<= 2.3.2) glibc.
Signed-off-by: Fabio M. Di Nitto <fabbione@fabbione.net>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This converts the usage of struct of_match to struct of_device_id,
similar to pci_device_id. This allows a device table to be generated,
which can be parsed by depmod(8) to generate a map file for module
loading.
In order for hotplug to work with macio devices, patches to
module-init-tools and hotplug must be applied. Those patches are
available at:
ftp://ftp.suse.com/pub/people/jeffm/linux/macio-hotplug/
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Another attempt at that...
The attached patch fixes the longstanding problem with USB bcdDevice
numeric ranges incorrectly converted into patterns for MODULE_ALIAS
generation. Previously it put both the lower and the upper limits into
the pattern, dlXdhY, making it impossible to fnmatch against except for
a few special cases, like dl*dh* or dlXdhX.
The patch makes it generate multiple MODULE_ALIAS lines covering the
whole range with fnmatch-able patterns. E.g. for a range between 0x0001
and 0x8345 it gives the following patterns:
000[1-9]
00[1-9]*
0[1-9]*
[1-7]*
8[0-2]*
83[0-3]*
834[0-5]
Since bcdDevice is 2 bytes wide = 4 digits in hex representation, the
max no. of patters is 2 * 4 - 1 = 7.
The values are BCD (binary-coded decimals) and not hex, so patterns
using a dash seem to be safe regardless of locale collation order.
The patch changes bcdDevice part of the alias from dlXdhY to dZ, but
this shouldn't have big compatibility issues because fnmatch()-based
modprobing hasn't yet been widely used. Besides, the most common (and
almost the only working) case of dl*dh* becomes d* and thus continues to
work.
The patch is against 2.6.12-rc2, applies to -mm3 with an offset. The
matching patch to fix the MODALIAS environment variable now generated by
the usb hotplug function follows.
Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Sam Ravnborg