* Russell King - ARM Linux [off-list ref] wrote:

On Thu, Oct 30, 2014 at 01:26:06AM -0700, Christoph Hellwig wrote:

quoted

On Wed, Oct 29, 2014 at 11:06:58PM +0100, Rabin Vincent wrote:

quoted

ARM has some private syscalls (for example, set_tls(2)) which lie
outside the range of NR_syscalls.  If any of these are called while
syscall tracing is being performed, out-of-bounds array access will
occur in the ftrace and perf sys_{enter,exit} handlers.

While this patch looks like good caution, having syscalls 
outside of NR_syscalls seems like a receipe for a disaster.  
Can you try to fix that issue as ell, please?

No.  We've had them since the inception of Linux on ARM.  They 
predate this tracing crap by more than a decade.  We're not 
changing them because that would be a massive user API 
breakage.

So if you go around calling other people's code 'crap' so easily: 
if we should call something 'crap' in this area it's the decision 
of ARM to deviate from all other architectures arbitrarily and to 
introduce 'private' syscalls outside NR_syscalls...

There's a reason why we have NR_syscalls with relatively tighly 
packed syscall numbers and there's a reason why we don't do 
'private' syscalls on other architectures.

I'd probably have NAK-ed ARM's 'private syscalls' had I known 
about it when this was introduced for ARM. IMO you should be 
ashamed for it instead of blaming others for the complication ...

But yes, it's probably an ABI, albeit a crappy one, which is now 
hurting the introduction of a generic kernel facility in the ARM 
space.

Thanks,

	Ingo