[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwdxjCjqSOR92GCz4Au9QLekWL_0zumnOyG-sxayDtfzg@mail.gmail.com>
Date: Sat, 17 Mar 2018 11:19:55 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Dominik Brodowski <linux@...inikbrodowski.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: what the hell is compat_sys_x86_waitpid() for?
On Sat, Mar 17, 2018 at 11:01 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> and tell me what is the difference between those. In other words, the problem
> with sys32_waitpid() was not that it didn't use proper wrappers - it's that
> it was (and always had been) 100% pointless.
That long long predates Dominik's patches, though.
It clearly is worth fixing, but don't blame Dominik for just
mindlessly converting mindless code.
> For fsck sake, look at the arguments. waitpid(2) takes pid_t, pointer to int
> and an int. How the hell could it possibly have required a compat wrapper?
This seems to go all the way back to the original x86_64 merge in
2002, with the original version of arch/x86_64/ia32/sys_ia32.c
containing
asmlinkage long
sys32_waitpid(__kernel_pid_t32 pid, unsigned int *stat_addr, int options)
{
return sys32_wait4(pid, stat_addr, options, NULL);
}
and it has only been modified syntactically since.
I suspect the reason is simply that the *regular* waitpid() was writtn
in terms of sys_wait4(), and sys_wait4() needed a compat function, so
then waitpid was basically just carried along.
Linus
Powered by blists - more mailing lists