| 55f0fb6adb83a5883589e945cbce37e90615ea09 |
|
08-Aug-2014 |
Andrey Ryabinin <a.ryabinin@samsung.com> |
ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations
Kernel module build with GCOV profiling fails to load with the
following error:
$ insmod test_module.ko
test_module: unknown relocation: 38
insmod: can't insert 'test_module.ko': invalid module format
This happens because constructor pointers in the .init_array section
have not supported R_ARM_TARGET1 relocation type.
Documentation (ELF for the ARM Architecture) says:
"The relocation must be processed either in the same way as R_ARM_REL32 or
as R_ARM_ABS32: a virtual platform must specify which method is used."
Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1
relocation type should be treated the same way as R_ARM_ABS32.
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 40c3baa7c66f1352521378ee83509fb8f4c465de |
|
13-Nov-2013 |
Jianguo Wu <wujianguo@huawei.com> |
mm/arch: use NUMA_NO_NODE
Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| f592d323bc2353db871d1e840f05b27e0730fb10 |
|
19-Jul-2013 |
Ben Dooks <ben.dooks@codethink.co.uk> |
ARM: module: correctly relocate instructions in BE8
When in BE8 mode, our instructions are not in the same ordering as the
data, so use <asm/opcodes.h> to take this into account.
Note, also requires modules to be built --be8
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
|
| 849b882b52df0f276d9ffded01d85654aa0da422 |
|
29-Aug-2013 |
Douglas Anderson <dianders@chromium.org> |
ARM: 7829/1: Add ".text.unlikely" and ".text.hot" to arm unwind tables
It appears that gcc may put some code in ".text.unlikely" or
".text.hot" sections. Right now those aren't accounted for in unwind
tables. Add them.
I found some docs about this at:
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf
Without this, if you have slub_debug turned on, you can get messages
that look like this:
unwind: Index not found 7f008c50
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 40b313608ad4ea655addd2ec6cdd106477ae8e15 |
|
21-May-2013 |
Stephen Rothwell <sfr@canb.auug.org.au> |
Finally eradicate CONFIG_HOTPLUG
Ever since commit 45f035ab9b8f ("CONFIG_HOTPLUG should be always on"),
it has been basically impossible to build a kernel with CONFIG_HOTPLUG
turned off. Remove all the remaining references to it.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
| e73fc88e19d74fd4dd664cff45b88caab8cde45c |
|
23-Aug-2011 |
Catalin Marinas <catalin.marinas@arm.com> |
ARM: 7059/1: LPAE: Use PMD_(SHIFT|SIZE|MASK) instead of PGDIR_*
PGDIR_SHIFT and PMD_SHIFT for the classic 2-level page table format have
the same value (21). This patch converts the PGDIR_* uses in the kernel
to the PMD_* equivalent so that LPAE builds can reuse the same code.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 20feaab0323cc062b298c12e77869424df05f31f |
|
04-Aug-2011 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: Fix build error for SMP=n builds
Unfortunately, the module fixups cause the kernel to fail to build
when SMP is not enabled. Fix this by removing the reference to
fixup_smp on non-SMP fixup kernels, but ensuring that if we do have
the SMP fixup section, we refuse to load the module.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 66574cc05438dd0907029075d7e6ec5ac0036fbc |
|
30-Jun-2011 |
Jonas Bonn <jonas@southpole.se> |
modules: make arch's use default loader hooks
This patch removes all the module loader hook implementations in the
architecture specific code where the functionality is the same as that
now provided by the recently added default hooks.
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
| 9a00318eadbb43db4e9c163c262a22a3c8b5a672 |
|
16-Jun-2011 |
Dave Martin <dave.martin@linaro.org> |
ARM: 6963/1: Thumb-2: Relax relocation requirements for non-function symbols
The "Thumb bit" of a symbol is only really meaningful for function
symbols (STT_FUNC).
However, sometimes a branch is relocated against a non-function
symbol; for example, PC-relative branches to anonymous assembler
local symbols are typically fixed up against the start-of-section
symbol, which is not a function symbol. Some inline assembler
generates references of this type, such as fixup code generated by
macros in <asm/uaccess.h>.
The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24
interprets this case as an error, because the target symbol appears
to be an ARM symbol; but this is really not the case, since the
target symbol is just a base in these cases. The addend defines
the precise offset to the target location, but since the addend is
encoded in a non-interworking Thumb branch instruction, there is no
explicit Thumb bit in the addend. Because these instructions never
interwork, the implied Thumb bit in the addend is 1, and the
destination is Thumb by definition.
This patch removes the extraneous Thumb bit check for non-function
symbols, enabling modules containing the affected relocation types
to be loaded. No modification to the actual relocation code is
required, since this code does not take bit[0] of the
location->destination offset into account in any case.
Function symbols are always checked for interworking conflicts, as
before.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 68e6fad488ef21335529c65ca6c88c38be50cd3a |
|
11-Jan-2011 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: improve module relocation fixup diagnostics
Current diagnostics are rather poor when things go wrong:
ipv6: relocation out of range, section 2 reloc 0 sym 'snmp_mib_free'
Let's include a little more information about the problem:
ipv6: section 2 reloc 0 sym 'snmp_mib_free': relocation 28 out of range (0xbf0000a4 -> 0xc11b4858)
so that we show exactly what the problem is - not only what type of
relocation but also the offending address range too.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| dc21af99fadcfa0ae65b52fd0895f85824f0c288 |
|
04-Jan-2011 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching
This idea came from Nicolas, Eric Miao produced an initial version,
which was then rewritten into this.
Patch the physical to virtual translations at runtime. As we modify
the code, this makes it incompatible with XIP kernels, but allows us
to achieve this with minimal loss of performance.
As many translations are of the form:
physical = virtual + (PHYS_OFFSET - PAGE_OFFSET)
virtual = physical - (PHYS_OFFSET - PAGE_OFFSET)
we generate an 'add' instruction for __virt_to_phys(), and a 'sub'
instruction for __phys_to_virt(). We calculate at run time (PHYS_OFFSET
- PAGE_OFFSET) by comparing the address prior to MMU initialization with
where it should be once the MMU has been initialized, and place this
constant into the above add/sub instructions.
Once we have (PHYS_OFFSET - PAGE_OFFSET), we can calculate the real
PHYS_OFFSET as PAGE_OFFSET is a build-time constant, and save this for
the C-mode PHYS_OFFSET variable definition to use.
At present, we are unable to support Realview with Sparsemem enabled
as this uses a complex mapping function, and MSM as this requires a
constant which will not fit in our math instruction.
Add a module version magic string for this feature to prevent
incompatible modules being loaded.
Tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 4a9cb360197684a861bc06f06d33d5fcc8ffcbf5 |
|
10-Feb-2011 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: fixup SMP alternatives in modules
With certain configurations, we inline the unlock functions in modules,
which results in SMP alternatives being created in modules. We need to
fix those up when loading a module to prevent undefined instruction
faults.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| d0a21265dfb5fa8ae54e90d0fb6d1c215b10a28a |
|
14-Jan-2011 |
David Rientjes <rientjes@google.com> |
mm: unify module_alloc code for vmalloc
Four architectures (arm, mips, sparc, x86) use __vmalloc_area() for
module_init(). Much of the code is duplicated and can be generalized in a
globally accessible function, __vmalloc_node_range().
__vmalloc_node() now calls into __vmalloc_node_range() with a range of
[VMALLOC_START, VMALLOC_END) for functionally equivalent behavior.
Each architecture may then use __vmalloc_node_range() directly to remove
the duplication of code.
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| 50005a8deb38e5e6456ebd94e57adb321d4589de |
|
12-Nov-2010 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: module: ignore unwind for sections not marked SHF_ALLOC
If a section is not marked with SHF_ALLOC, it will be discarded
by the module code. Therefore, it is not correct to register
the unwind tables.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 8931360eb9c6ec8bd30efef579cef81917a2fcf3 |
|
12-Nov-2010 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: module: clean up handling of ELF unwind tables
There's no need to keep pointers to the ELF sections available while
the module is loaded - we only need the section pointers while we're
finding and registering the unwind tables, which can all be done during
the finalize stage of loading.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 09e56a2d076c2afb2a1932ae4283e10ef2d26ef3 |
|
19-Aug-2010 |
Phil Carmody <ext-phil.2.carmody@nokia.com> |
ARM: 6340/1: module - additional unwind tables for exit/devexit sections
Without these, exit functions cannot be stack-traced, so to speak.
This implies that module unloads that perform allocations (don't
laugh) will cause noisy warnings on the console when kmemleak is
enabled, as it presumes that all code's call chains are traceable.
Similarly, BUGs and WARN_ONs will give additional console spam.
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| e5f7772eec3ec342ecfe686ab8330ef538af134b |
|
19-Aug-2010 |
Phil Carmody <ext-phil.2.carmody@nokia.com> |
ARM: 6339/1: module - simplify unwind table handling
The various sections are all dealt with similarly, so factor out
that common behaviour. (Incorporating Peter Huewe's fix.)
Cc: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 5793432628ad76f93ae4d31c23fb1c26e3d8b525 |
|
19-Aug-2010 |
Phil Carmody <ext-phil.2.carmody@nokia.com> |
ARM: 6338/1: module - simplify code with temporaries
Less to read.
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| b749315601b44a63634d1a38fd167b8cac0e9ad4 |
|
21-Jun-2010 |
Catalin Marinas <catalin.marinas@arm.com> |
ARM: 6191/1: Do not compile the Thumb-2 module relocations on an ARM kernel
Kernels compiled to ARM do not need to handle Thumb-2 module relocations
as interworking is not allowed. This patch #ifdef's out the handling of
such relocations.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 0567821cd8aac3f390282e02c9ba633894cbf7c1 |
|
21-Jun-2010 |
Catalin Marinas <catalin.marinas@arm.com> |
ARM: 6190/1: Remove dummy loads from the original relocation address
Reading back the upper and lower values in the R_ARM_THM_CALL and
R_ARM_THM_JUMP24 case was introduced by a previous commit but they are
not needed.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 8dd47741d191400c46173ed9fba9d14b4033ce23 |
|
21-Jun-2010 |
Catalin Marinas <catalin.marinas@arm.com> |
ARM: 6189/1: Add support for the MOVW/MOVT relocations in Thumb-2
The patch adds handling case for the R_ARM_THM_MOVW_ABS_NC and
R_ARM_THM_MOVT_ABS relocations in arch/arm/kernel/module.c. Such
relocations may appear in Thumb-2 compiled kernel modules.
Reported-by: Kyungmin Park <kmpark@infradead.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 5a0e3ad6af8660be21ca98a971cd00f331318c05 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
| adca6dc23bc620ea95392659625200a252b97be3 |
|
24-Jul-2009 |
Catalin Marinas <catalin.marinas@arm.com> |
Thumb-2: Add support for loadable modules
Modules compiled to Thumb-2 have two additional relocations needing to
be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
(+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
(MODULES_END - 8MB) for the Thumb-2 compiled kernel.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
| ae51e609843f7d0aaeb1c2ad9f89d252a4899885 |
|
07-May-2009 |
Paul Gortmaker <paul.gortmaker@gmail.com> |
[ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To fully support the armv7-a instruction set/optimizations, support
for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is
required.
The MOVW and MOVT are both load-immediate instructions, MOVW loads 16
bits into the bottom half of a register, and MOVT loads 16 bits into the
top half of a register.
The relocation information for these instructions has a full 32 bit
value, plus an addend which is stored in the 16 immediate bits in the
instruction itself. The immediate bits in the instruction are not
contiguous (the register # splits it into a 4 bit and 12 bit value),
so the addend has to be extracted accordingly and added to the value.
The value is then split and put into the instruction; a MOVW uses the
bottom 16 bits of the value, and a MOVT uses the top 16 bits.
Signed-off-by: David Borman <david.borman@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 4731f8b66dd34ebf0e67ca6ba9162b0e509bec06 |
|
20-Mar-2009 |
Daniel Silverstone <dsilvers@simtec.co.uk> |
[ARM] 5428/1: Module relocation update for R_ARM_V4BX
It would seem when building kernel modules with modern binutils
(required by modern GCC) for ARM v4T targets (specifically observed
with the Samsung 24xx SoC which is an 920T) R_ARM_V4BX relocations
are emitted for function epilogues.
This manifests at module load time with an "unknown relocation: 40"
error message.
The following patch adds the R_ARM_V4BX relocation to the ARM kernel
module loader. The relocation operation is taken from that within the
binutils bfd library.
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: Vincent Sanders <vince@simtec.co.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 2e1926e7b5d39eb31880152d636e8d8d011888cb |
|
11-Feb-2009 |
Catalin Marinas <catalin.marinas@arm.com> |
[ARM] 5384/1: unwind: Add stack unwinding support for loadable modules
This patch adds ELF section parsing for the unwinding tables in loadable
modules together with the PREL31 relocation symbol resolving.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 37efe6427dd50e889473fb3c7fcec02dbbd098eb |
|
01-Dec-2008 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[ARM] use asm/sections.h
Update to use the asm/sections.h header rather than declaring these
symbols ourselves. Change __data_start to _data to conform with the
naming found within asm/sections.h.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| ab4f2ee130d5ffcf35616e1f5c6ab75af5b463b6 |
|
06-Nov-2008 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[ARM] fix naming of MODULE_START / MODULE_END
As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, the kernel needs
to know where modules are located in the virtual address space.
On ARM, we located this region between MODULE_START and MODULE_END.
Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
Update ARM to use the same naming, so is_vmalloc_or_module_addr()
can work properly. Also update the comment on mm/vmalloc.c to
reflect that ARM also places modules in a separate region from the
vmalloc space.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 8ec53663d2698076468b3e1edc4e1b418bd54de3 |
|
07-Sep-2008 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[ARM] Improve non-executable support
Add support for detecting non-executable stack binaries, and adjust
permissions to prevent execution from data and stack areas. Also,
ensure that READ_IMPLIES_EXEC is enabled for older CPUs where that
is true, and for any executable-stack binary.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 27ac792ca0b0a1e7e65f20342260650516c95864 |
|
24-Jul-2008 |
Andrea Righi <righi.andrea@gmail.com> |
PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architectures
On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
boundary. For example:
u64 val = PAGE_ALIGN(size);
always returns a value < 4GB even if size is greater than 4GB.
The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
example):
#define PAGE_SHIFT 12
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))
...
#define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)
The "~" is performed on a 32-bit value, so everything in "and" with
PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
Using the ALIGN() macro seems to be the right way, because it uses
typeof(addr) for the mask.
Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
include/linux/mm.h.
See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
[akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
[akpm@linux-foundation.org: fix v850]
[akpm@linux-foundation.org: fix powerpc]
[akpm@linux-foundation.org: fix arm]
[akpm@linux-foundation.org: fix mips]
[akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
[akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
[akpm@linux-foundation.org: fix powerpc]
Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| c5f125031f416ba6350e84462e9039737b6e2bab |
|
08-May-2007 |
Kevin Welton <Kevin.Welton@arm.com> |
[ARM] Fix ARM branch relocation range
Branches in the ARM architecture are restricted to a range of +/- 32MB.
However, the code in .../arch/arm/kernel/module.c::apply_relocate() was
checking offset against a range of +/- 64MB.
Signed-off-by: Kevin Welton <Kevin.Welton@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 6a570b28b5948e7bf54ea42ec3161bded0a1c460 |
|
26-Sep-2006 |
Hyok S. Choi <hyok.choi@samsung.com> |
[ARM] nommu: allows to support module in nommu
A simple patch to support module in nommu mode.
The vmalloc is used instead of __vmalloc_area which depends on CONFIG_MMU.
Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 6ab3d5624e172c553004ecc862bfeac16d9d68b7 |
|
30-Jun-2006 |
Jörn Engel <joern@wohnheim.fh-wedel.de> |
Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
| c2e2611425a956d25d2948c5d95d3848c4db1257 |
|
14-Dec-2005 |
Daniel Jacobowitz <drow@false.org> |
[ARM] 3205/1: Handle new EABI relocations when loading kernel modules.
Patch from Daniel Jacobowitz
Handle new EABI relocations when loading kernel modules. This is
necessary for CONFIG_AEABI kernels, and also for some broken
(since fixed) old ABI toolchains.
Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| f339ab3d6c59f8f898c165384aa2b6a0ae5d4c1c |
|
28-Oct-2005 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[ARM] Fix sparse warnings
Fix sparse warnings in arch/arm/kernel/module.c,
arch/arm/mm/consistent.c, drivers/pcmcia/sa1111_generic.c,
and platform support files.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 |
|
17-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2
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!
|