]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC r240997:
authortrociny <trociny@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Mon, 19 Nov 2012 21:11:58 +0000 (21:11 +0000)
committertrociny <trociny@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Mon, 19 Nov 2012 21:11:58 +0000 (21:11 +0000)
commitb00f219e80ebf46021c57c5a41551ba097f93a6f
tree5a590ae81587f39cd09bec6dd26ca693ee4141c5
parentff6691ad6dfaeeeac34cae201bad8f934fdce229
MFC r240997:

Kernel and modules have "set_vnet" linker set, where virtualized
global variables are placed. When a module is loaded by link_elf
linker its variables from "set_vnet" linker set are copied to the
kernel "set_vnet" ("modspace") and all references to these variables
inside the module are relocated accordingly.

The issue is when a module is loaded that has references to global
variables from another, previously loaded module: these references are
not relocated so an invalid address is used when the module tries to
access the variable. The example is V_layer3_chain, defined in ipfw
module and accessed from ipfw_nat.

The same issue is with DPCPU variables, which use "set_pcpu" linker
set.

Fix this making the link_elf linker on a module load recognize
"external" DPCPU/VNET variables defined in the previously loaded
modules and relocate them accordingly. For this set_pcpu_list and
set_vnet_list are used, where the addresses of modules' "set_pcpu" and
"set_vnet" linker sets are stored.

Note, archs that use link_elf_obj (amd64) were not affected by this
issue.

Reviewed by: jhb, julian, zec (initial version)

git-svn-id: svn://svn.freebsd.org/base/stable/8@243309 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/kern/link_elf.c