On 09/02/2014 06:16 PM, Russell King - ARM Linux wrote:
On Tue, Sep 02, 2014 at 05:47:29PM +0900, AKASHI Takahiro wrote:
On 09/01/2014 08:47 PM, Russell King - ARM Linux wrote:
On Wed, Aug 27, 2014 at 02:55:46PM +0900, AKASHI Takahiro wrote:
setting x0 to -ENOSYS is necessary because, otherwise, user-issued syscall(-1) will return a bogus value when audit tracing is on.
Please note that, on arm, not traced traced ------ ------ syscall(-1) aborted OOPs(BUG_ON) syscall(-3000) aborted aborted syscall(1000) ENOSYS ENOSYS
Two points here:
- You've found a case which causes a BUG_ON(). Where is the bug report for this, so the problem can be investigated and resolved?
I think that I mentioned it could also happen on arm somewhere in a talk with Will, but don't remember exactly when.
Sorry, not good enough. Please report this bug so it can be investigated and fixed.
Please review my patch as well as the commit message.
- What do you mean by "aborted" ?
I mean that the process will receive SIGILL and get aborted. A system call number, like -1 and -3000, won't be trapped by *switch* statement in asm_syscall() and end up with being signaled.
That is correct behaviour - because numbers greater than 0xf0000 (or 0x9f0000 for OABI - the 0x900000 offset on the syscalls on OABI is to distinguish them from syscalls used by RISC OS) are not intended to be Linux syscalls per-se.
I tried to make such invalid/pseudo syscalls hehave in the same way whether or not a task is traced (by seccomp, ptrace or audit).
Please, if you find a problem with 32-bit ARM, report it. Don't hide it, because hiding it can be a security issue or in the case of BUG_ON(), it could be a denial of service issue.
As you're part of Linaro, I would have thought you'd be more responsible in this regard - after all, Linaro is supposed to be about improving the ARM kernel... Maybe I got that wrong, and Linaro is actually about ensuring that the ARM kernel is stuffed full of broken features?
I thought my first priority was on arm64 (and then arm), but now that you and Will seem to want to see the fix first on arm, okey, I will start with arm issue.
So what you're saying there is that if you find a bug in ARM code, which everyone is currently using, you can ignore it until you've sorted out ARM64 which almost no one is using.
This is absurd, and whoever has set your priorities is clearly on drugs.
Thank you. I learned a new English word, absurd.
-Takahiro AKASHI