From mboxrd@z Thu Jan  1 00:00:00 1970
From: michael.weiser@gmx.de (Michael Weiser)
Date: Sun, 21 Jan 2018 18:44:01 +0100
Subject: arm64: Unimplemented syscall kernel message
Message-ID: <20180121174401.GA44039@dinsnail.net>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Hello Catalin and Will,

I'd like ask your opinion as arm64 Linux port maintainers and initial
authors of the code in question regarding kernel messages on
unimplemented system calls. I apologise in advance if that isn't the
right approach (and Cc: linux-arm :).

Currently, a programm doing an unimplemented syscall triggers a rather
scary looking kernel message:

[  189.143682] glibc-test[2118]: syscall 1000
[  189.143728] Code: aa0503e4 aa0603e5 aa0703e6 d4000001 (b13ffc1f) 
[  189.143750] CPU: 1 PID: 2118 Comm: glibc-test Not tainted 4.15.0-rc7-00232-g2c1cfa499018 #3
[  189.143755] Hardware name: SoPine with baseboard (DT)
[  189.143762] pstate: 80000000 (Nzcv daif -PAN -UAO)
[  189.143774] pc : 0xffffb8fb0104
[  189.143779] lr : 0xaaaab43c563c
[  189.143781] sp : 0000ffffd4fa1180
[  189.143786] x29: 0000ffffd4fa1190 x28: 0000000000000000 
[  189.143795] x27: 0000000000000000 x26: 0000000000000000 
[  189.143802] x25: 0000000000000000 x24: 0000000000000000 
[  189.143809] x23: 0000000000000000 x22: 0000000000000000 
[  189.143816] x21: 0000aaaab43c564c x20: 0000000000000000 
[  189.143823] x19: 0000aaaab43c5770 x18: 0000000000000a03 
[  189.143829] x17: 0000aaaab43d6020 x16: 0000ffffb8fb00e0 
[  189.143837] x15: 0000ffffb8ed4000 x14: 0000ffffb8ed7540 
[  189.143844] x13: 0000ffffb8ee45d8 x12: 0000000000000000 
[  189.143851] x11: 0000000000000020 x10: 0000000000000000 
[  189.143857] x9 : 00000000000000ff x8 : 00000000000003e8 
[  189.143864] x7 : e607cc2262a01600 x6 : e607cc2262a01600 
[  189.143872] x5 : 0000ffffd4fa12c0 x4 : 0000000000000000 
[  189.143879] x3 : 0000000000000000 x2 : 0000aaaab43c5630 
[  189.143886] x1 : 0000ffffd4fa12d8 x0 : 0000ffffd4fa12c8 

It requires some digging to find that this basically is a
debugging/warning message and can be disabled using
/proc/sys/debug/exception-trace
(arm64/kernel/traps.c:do_ni_syscall,show_unhandled_signals_ratelimited).

Other platforms do not seem to do this, even with exception-trace
enabled - x86_64 and arm for sure. Instead they silently return -ENOSYS.

There are a number of other kernel messages governed by the same sysctl
(fault.c:__do_user_fault,do_sp_pc_abort, traps.c:force_signal_inject,
signal.c:sys_rt_sigreturn).

Can I in good conscience disable exception-trace on the affected
(production) systems or would this mask other, more critical
misbehaviour?

Is it actually considered misbehaviour for arm64 userland to even
attempt such a call? Or is the message maybe just a left-over development
aid?

Can it perhaps be removed or disabled by default, considering that with
future addition of syscalls userland will likely start triggering this
message a lot when run on older kernels?
-- 
Thanks,
Michael