[ARM] safer handling of syscall table padding

ARM entry-common.S needs to know syscall table size; in itself that would
not be a problem, but there's an additional constraint - some of the
instructions using it want a constant that would be a multiple of 4.
So we have to pad syscall table with sys_ni_syscall and that's where
the trouble begins.  .rept pseudo-op wants a constant expression for
number of repetitions and subtraction of two labels (before and after
syscall table) doesn't always get simplified to constant early enough
for .rept.  If labels end up in different frags, we lose.  And while
the frag size is large enough (slightly below 4Kb), the syscall table
is about 1/3 of that.  We used to get away with that, but the recent
changes had been enough to trigger the breakage.

Proper fix is simple: have a macro (CALL(x)) to populate the table
instead of using explicit .long x and the first time we include calls.S
have it defined to .equ NR_syscalls,NR_syscalls+1.  Then we can find
the proper amount of padding on the first inclusion simply by looking
at NR_syscalls at that time.  And that will be constant, no matter what.

Moreover, the same trick kills the need of having an estimate of padded
NR_syscalls - it will be calculated for free at the same time.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

1 files changed, 4 insertions, 0 deletions

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 2b92ce8..dbcb11a 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -87,7 +87,11 @@ ENTRY(ret_from_fork)
 	b	ret_slow_syscall
 	
 
+	.equ NR_syscalls,0
+#define CALL(x) .equ NR_syscalls,NR_syscalls+1
 #include "calls.S"
+#undef CALL
+#define CALL(x) .long x
 
 /*=============================================================================
  * SWI handler