On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote:

On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:

quoted

On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:

quoted

On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote:

quoted

On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:

quoted

New aarch32 ptrace syscall handler is introduced to avoid run-time
detection of the task type.

What's wrong with the run-time detection? If it's just to avoid a
negligible overhead, I would rather keep the code simpler by avoiding
duplicating the generic compat_sys_ptrace().

Nothing wrong. This is how Arnd asked me to do. You already asked this
question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html

Hmm, I completely forgot about this ;). There is still an advantage to
doing run-time checking if we avoid touching core code (less acks to
gather and less code duplication).

Let's see what Arnd says but the initial patch looked simpler.

I don't currently have either version of the patch in my inbox
(the archive is on a different machine), but in general I'd still
think it's best to avoid the runtime check for aarch64-ilp32
altogether. I'd have to look at the overall kernel source to
see if it's worth avoiding one or two instances though, or
if there are an overwhelming number of other checks that we
can't avoid at all.

Regarding ptrace, I notice that arch/tile doesn't even use
the compat entry point for its ilp32 user space on 64-bit
kernels, it just calls the regular 64-bit one. Would that
help here?

ILP32 tasks has unique context that is not like aarch64 or aarch32,
so we have to have unique ptrace handler. I prepared the patch for
ptrace with runtime ABI detection, as Catalin said, see there:
https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670

If it's OK, I'd like to update submission.

Yury