Re: [PATCH] [RFC] syscalls,x86: Add execveat() system call (v2)

On Thu, Aug 2, 2012 at 7:55 AM, Al Viro [off-list ref] wrote:

quoted

This means you need an x32 version of the function -- execve
unfortunately is one of the few system calls which require a special x32
version (although it's a simple wrapper around sys32_execve).  See
sys_x32_execve.

I *really* strongly object to doing that thing before we sanitize the
situation with sys_execve().

"That thing" = "creating an x32 entry stub", or "merging execveat() at all"?

(snip)

The thing is, there's essentially no reason to have more than one
implementation.  What they are (badly) doing is "we need to find
pt_regs to pass to do_execve(), the thing we are after has to be near
our stack frame, so let's try to get to it that way".

Hang on...it's not just sys_execve that fits that description, is it?
You seem to be describing every call that needs a pt_regs parameter,
which at a glance is anything with a stub_ or PTREGSCALL in
arch/x86/kernel/entry_{32,64}.S. That's: clone, fork, vfork,
sigaltstack, iopl, execve, sigreturn, rt_sigreturn, vm86, vm86old.
Most of those are handled by a common PTREGSCALL macro, but there are
a few that get special treatment (different set on each arch - on
x86-64 it's execve and rt_sigreturn ; on i386 it's just clone).

Is there's something special about execve in particular, or do you
want to overhaul all the ptregscalls?

Meredydd