Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*My\s+sys32

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*My\s+sys32_execve\.\s*$/: 14 ]

Total 14 documents matching your query.

1. My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Wed, 1 Mar 2000 23:57:21 +0100; As per our phone conference from yesterday, this is my variant of sys32_execve which compiles and works fine. It's very similar to the Sparc64 code, just derived from more recent code than it. Ralf /; /archives/linux-origin/2000-03/msg00001.html (12,321 bytes)
2. Re: My sys32_execve(). (score: 1): Author: kanoj@xxxxxxxxxxxxxxxxxxx (Kanoj Sarcar); Date: Wed, 1 Mar 2000 15:06:37 -0800 (PST); Umm, didn't I just check this in a couple of days back? Look at sys32_execve() in arch/mips64/kernel/linux32.c. Its a variant of the ia64 ia32-support code. Kanoj; /archives/linux-origin/2000-03/msg00002.html (7,641 bytes)
3. Re: My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Thu, 2 Mar 2000 00:19:22 +0100; Not unless you are better at hacking than the NSA because this code has never reached a machine connected to the net :-) The similarity is natural, I just sent this for your interest because of yeste; /archives/linux-origin/2000-03/msg00003.html (8,214 bytes)
4. Re: My sys32_execve(). (score: 1): Author: kanoj@xxxxxxxxxxxxxxxxxxx (Kanoj Sarcar); Date: Wed, 1 Mar 2000 15:34:15 -0800 (PST); No no, I meant a version of sys32_execve, not the exact code that you sent. Actually, if you look at the checked in version of sys32_execve, it is quite different from the sparc version (_much_ less; /archives/linux-origin/2000-03/msg00004.html (8,797 bytes)
5. Re: My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Thu, 2 Mar 2000 01:21:15 +0100; The rules that I've been using is ``shit in, shit out'', that is I never try to catch arguments that aren't valid for 32-bit syscalls like passing addresses that aren't valid in a 32-bit world. That; /archives/linux-origin/2000-03/msg00005.html (8,566 bytes)
6. Re: My sys32_execve(). (score: 1): Author: kanoj@xxxxxxxxxxxxxxxxxxx (Kanoj Sarcar); Date: Wed, 1 Mar 2000 16:31:43 -0800 (PST); We are probably ages away from when TASK_SIZE will be a problem, but get_unmapped_area() will return success for 32 bit programs when it really should not, in certain cases. Tweaking TASK_UNMAPPED_B; /archives/linux-origin/2000-03/msg00006.html (8,230 bytes)
7. Re: My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Thu, 2 Mar 2000 01:33:43 +0100; On MIPS we also want our private get_unmapped_area, even though for other reasons that don't apply to the R10000. We want it because carefully placing of mappings in the virtual address space is part; /archives/linux-origin/2000-03/msg00007.html (8,622 bytes)
8. My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Wed, 1 Mar 2000 23:57:21 +0100; As per our phone conference from yesterday, this is my variant of sys32_execve which compiles and works fine. It's very similar to the Sparc64 code, just derived from more recent code than it. Ralf /; /archives/linux-origin/2000-03/msg00043.html (12,321 bytes)
9. Re: My sys32_execve(). (score: 1): Author: kanoj@xxxxxxxxxxxxxxxxxxx (Kanoj Sarcar); Date: Wed, 1 Mar 2000 15:06:37 -0800 (PST); Umm, didn't I just check this in a couple of days back? Look at sys32_execve() in arch/mips64/kernel/linux32.c. Its a variant of the ia64 ia32-support code. Kanoj; /archives/linux-origin/2000-03/msg00044.html (7,669 bytes)
10. Re: My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Thu, 2 Mar 2000 00:19:22 +0100; Not unless you are better at hacking than the NSA because this code has never reached a machine connected to the net :-) The similarity is natural, I just sent this for your interest because of yeste; /archives/linux-origin/2000-03/msg00045.html (8,300 bytes)
11. Re: My sys32_execve(). (score: 1): Author: kanoj@xxxxxxxxxxxxxxxxxxx (Kanoj Sarcar); Date: Wed, 1 Mar 2000 15:34:15 -0800 (PST); No no, I meant a version of sys32_execve, not the exact code that you sent. Actually, if you look at the checked in version of sys32_execve, it is quite different from the sparc version (_much_ less; /archives/linux-origin/2000-03/msg00046.html (8,825 bytes)
12. Re: My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Thu, 2 Mar 2000 01:21:15 +0100; The rules that I've been using is ``shit in, shit out'', that is I never try to catch arguments that aren't valid for 32-bit syscalls like passing addresses that aren't valid in a 32-bit world. That; /archives/linux-origin/2000-03/msg00047.html (8,652 bytes)
13. Re: My sys32_execve(). (score: 1): Author: kanoj@xxxxxxxxxxxxxxxxxxx (Kanoj Sarcar); Date: Wed, 1 Mar 2000 16:31:43 -0800 (PST); We are probably ages away from when TASK_SIZE will be a problem, but get_unmapped_area() will return success for 32 bit programs when it really should not, in certain cases. Tweaking TASK_UNMAPPED_B; /archives/linux-origin/2000-03/msg00048.html (8,258 bytes)
14. Re: My sys32_execve(). (score: 1): Author: Ralf Baechle <ralf@xxxxxxxxxxx>; Date: Thu, 2 Mar 2000 01:33:43 +0100; On MIPS we also want our private get_unmapped_area, even though for other reasons that don't apply to the R10000. We want it because carefully placing of mappings in the virtual address space is part; /archives/linux-origin/2000-03/msg00049.html (8,708 bytes)

Current List: 1 - 14
Page: [1]