On 08/09/2012 12:19 PM, Andy Lutomirski wrote:
> On 08/01/2012 03:10 PM, Meredydd Luff wrote:
>>
>> +#ifndef sys_execveat
>> +asmlinkage long sys_execveat(int dfd, const char __user *filename,
>> + const char __user *const __user *argv,
>> + const c
On 08/01/2012 03:10 PM, Meredydd Luff wrote:
>
> +#ifndef sys_execveat
> +asmlinkage long sys_execveat(int dfd, const char __user *filename,
> + const char __user *const __user *argv,
> + const char __user *const __user *envp,
> +
On Thu, Aug 2, 2012 at 11:30 AM, Al Viro wrote:
> FWIW, I've just pushed (completely untested) arm and alpha
> parts of what I described into signal.git#execve2; x86 is
> next. Note that after that sys_execve() is identical on
> converted architectures and can be merged; ditto for
> kernel_execve
On Thu, Aug 02, 2012 at 10:14:53AM +0100, Meredydd Luff wrote:
> On Thu, Aug 2, 2012 at 7:55 AM, Al Viro wrote:
> >> 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 wrapp
On Thu, Aug 2, 2012 at 7:55 AM, Al Viro wrote:
>> 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* strongl
On Wed, Aug 01, 2012 at 04:30:22PM -0700, H. Peter Anvin wrote:
> On 08/01/2012 04:09 PM, Meredydd Luff wrote:
> >>> #
> >>> # x32-specific system call numbers start at 512 to avoid cache impact
> >>
> >> I think that should be common, not 64 (as should kcmp be).
> >
> > I copied the original ex
Sorry misunderstood your offlist mail I can cook up an x32 binary easily
enough.
Meredydd Luff wrote:
>On 2 Aug 2012 00:33, "H. Peter Anvin" wrote:
>> > Sorry, you're right. The argument vector needs compatibility
>support.
>> >
>> > This means you need an x32 version of the function
>
>Thi
On 08/01/2012 04:30 PM, H. Peter Anvin wrote:
> On 08/01/2012 04:09 PM, Meredydd Luff wrote:
#
# x32-specific system call numbers start at 512 to avoid cache impact
>>>
>>> I think that should be common, not 64 (as should kcmp be).
>>
>> I copied the original execve, which is 64.
>>
>
On 08/01/2012 04:09 PM, Meredydd Luff wrote:
>>> #
>>> # x32-specific system call numbers start at 512 to avoid cache impact
>>
>> I think that should be common, not 64 (as should kcmp be).
>
> I copied the original execve, which is 64.
>
Sorry, you're right. The argument vector needs compati
On Wed, Aug 1, 2012 at 11:53 PM, H. Peter Anvin wrote:
> On 08/01/2012 03:10 PM, Meredydd Luff wrote:
>> diff --git a/arch/x86/syscalls/syscall_64.tbl
>> b/arch/x86/syscalls/syscall_64.tbl
>> index 51171ae..c35df9e 100644
>> --- a/arch/x86/syscalls/syscall_64.tbl
>> +++ b/arch/x86/syscalls/syscal
On 08/01/2012 03:10 PM, Meredydd Luff wrote:
> diff --git a/arch/x86/syscalls/syscall_64.tbl
> b/arch/x86/syscalls/syscall_64.tbl
> index 51171ae..c35df9e 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -319,6 +319,7 @@
> 310 64 process_vm_readv
[v2 for style, CREDITS file is deprecated]
HPA is already on record calling for an execveat() which also does
fexecve()'s job: https://lkml.org/lkml/2006/7/11/556.
And the current glibc hack for fexecve() is already causing problems
in the wild. Eg: https://bugzilla.redhat.com/show_bug.cgi?id=2416
On 01.08.2012 23:44, Meredydd Luff wrote:
HPA is already on record calling for an execveat() which also does
fexecve()'s job: https://lkml.org/lkml/2006/7/11/556.
And the current glibc hack for fexecve() is already causing problems
in the wild. Eg: https://bugzilla.redhat.com/show_bug.cgi?id=2416
HPA is already on record calling for an execveat() which also does
fexecve()'s job: https://lkml.org/lkml/2006/7/11/556.
And the current glibc hack for fexecve() is already causing problems
in the wild. Eg: https://bugzilla.redhat.com/show_bug.cgi?id=241609,
https://lkml.org/lkml/2006/12/27/123, an
14 matches
Mail list logo
