linux.git/arch/arm/kernel/module.c, branch v3.17

ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations

2014-08-27T14:40:11+00:00

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 
Signed-off-by: Russell King

Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm

2013-11-13T23:51:29+00:00

Pull ARM updates from Russell King:
"Included in this series are:

1. BE8 (modern big endian) changes for ARM from Ben Dooks
2. big.Little support from Nicolas Pitre and Dave Martin
3. support for LPAE systems with all system memory above 4GB
4. Perf updates from Will Deacon
5. Additional prefetching and other performance improvements from Will.
6. Neon-optimised AES implementation fro Ard.
7. A number of smaller fixes scattered around the place.

There is a rather horrid merge conflict in tools/perf - I was never
notified of the conflict because it originally occurred between Will's
tree and other stuff. Consequently I have a resolution which Will
forwarded me, which I'll forward on immediately after sending this
mail.

The other notable thing is I'm expecting some build breakage in the
crypto stuff on ARM only with Ard's AES patches. These were merged
into a stable git branch which others had already pulled, so there's
little I can do about this. The problem is caused because these
patches have a dependency on some code in the crypto git tree - I
tried requesting a branch I can pull to resolve these, and all I got
each time from the crypto people was "we'll revert our patches then"
which would only make things worse since I still don't have the
dependent patches. I've no idea what's going on there or how to
resolve that, and since I can't split these patches from the rest of
this pull request, I'm rather stuck with pushing this as-is or
reverting Ard's patches.

Since it should "come out in the wash" I've left them in - the only
build problems they seem to cause at the moment are with randconfigs,
and since it's a new feature anyway. However, if by -rc1 the
dependencies aren't in, I think it'd be best to revert Ard's patches"

I resolved the perf conflict roughly as per the patch sent by Russell,
but there may be some differences. Any errors are likely mine. Let's
see how the crypto issues work out..

* 'for-linus' of git://git.linaro.org/people/rmk/linux-arm: (110 commits)
ARM: 7868/1: arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
ARM: 7867/1: include: asm: use 'int' instead of 'unsigned long' for 'oldval' in atomic_cmpxchg().
ARM: 7866/1: include: asm: use 'long long' instead of 'u64' within atomic.h
ARM: 7871/1: amba: Extend number of IRQS
ARM: 7887/1: Don't smp_cross_call() on UP devices in arch_irq_work_raise()
ARM: 7872/1: Support arch_irq_work_raise() via self IPIs
ARM: 7880/1: Clear the IT state independent of the Thumb-2 mode
ARM: 7878/1: nommu: Implement dummy early_paging_init()
ARM: 7876/1: clear Thumb-2 IT state on exception handling
ARM: 7874/2: bL_switcher: Remove cpu_hotplug_driver_{lock,unlock}()
ARM: footbridge: fix build warnings for netwinder
ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu
ARM: fix misplaced arch_virt_to_idmap()
ARM: 7848/1: mcpm: Implement cpu_kill() to synchronise on powerdown
ARM: 7847/1: mcpm: Factor out logical-to-physical CPU translation
ARM: 7869/1: remove unused XSCALE_PMU Kconfig param
ARM: 7864/1: Handle 64-bit memory in case of 32-bit phys_addr_t
ARM: 7863/1: Let arm_add_memory() always use 64-bit arguments
ARM: 7862/1: pcpu: replace __get_cpu_var_uses
ARM: 7861/1: cacheflush: consolidate single-CPU ARMv7 cache disabling code
...

mm/arch: use NUMA_NO_NODE

2013-11-13T03:09:05+00:00

Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()

Signed-off-by: Jianguo Wu 
Acked-by: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ARM: module: correctly relocate instructions in BE8

2013-10-19T19:46:35+00:00

When in BE8 mode, our instructions are not in the same ordering as the
data, so use  to take this into account.

Note, also requires modules to be built --be8

Signed-off-by: Ben Dooks 
Reviewed-by: Dave Martin

ARM: 7829/1: Add ".text.unlikely" and ".text.hot" to arm unwind tables

2013-09-02T12:49:47+00:00

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 
Acked-by: Mike Frysinger 
Signed-off-by: Russell King

Finally eradicate CONFIG_HOTPLUG

2013-06-03T21:20:18+00:00

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 
Cc: Doug Thompson 
Cc: Bjorn Helgaas 
Cc: Steven Whitehouse 
Cc: Arnd Bergmann 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
Cc: Andrew Morton 
Signed-off-by: Stephen Rothwell 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Hans Verkuil 
Signed-off-by: Greg Kroah-Hartman

ARM: 7059/1: LPAE: Use PMD_(SHIFT|SIZE|MASK) instead of PGDIR_*

2011-08-23T14:30:33+00:00

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 
Signed-off-by: Russell King

ARM: Fix build error for SMP=n builds

2011-08-04T07:24:29+00:00

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

modules: make arch's use default loader hooks

2011-07-24T12:36:04+00:00

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 
Acked-by: Mike Frysinger 
Acked-by: Geert Uytterhoeven 
Tested-by: Michal Simek 
Signed-off-by: Rusty Russell

ARM: 6963/1: Thumb-2: Relax relocation requirements for non-function symbols

2011-06-17T10:25:04+00:00

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 .

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 
Acked-by: Catalin Marinas 
Signed-off-by: Russell King