Quoting Justus Winter (2015-06-06 11:27:39)
Something along these lines? The patch is untested. It compiles fine
of course, but despite my best efforts and 8+ hours of cpu time my box
failed to build libc packages :/
Well, I disabled the tests, and the -686 and -xen variants. I never
came
Something along these lines? The patch is untested. It compiles fine
of course, but despite my best efforts and 8+ hours of cpu time my box
failed to build libc packages :/
Justus
Justus Winter, le Wed 03 Jun 2015 13:54:40 +0200, a écrit :
1/ Cache the [host] port in the libc like we do for the task port.
I'd say so, yes, there is no need for a kernel call here.
Samuel
Hello,
I independently rediscovered that host port leak. I see two options
how to proceed:
1/ Cache the port in the libc like we do for the task port.
2/ Cache/deallocate the port everywhere.
Given the fact that I found not a single call site of `mach_host_self'
(in both the Hurd and the libc)
On Wed, Jun 03, 2015 at 01:54:40PM +0200, Justus Winter wrote:
I independently rediscovered that host port leak. I see two options
how to proceed:
The host and task ports actually don't leak, because they're unique to
a task, and Mach treats them as exceptions by never overruning the user
Quoting Richard Braun (2015-06-03 14:10:16)
On Wed, Jun 03, 2015 at 01:54:40PM +0200, Justus Winter wrote:
I independently rediscovered that host port leak. I see two options
how to proceed:
The host and task ports actually don't leak, because they're unique to
a task, and Mach treats
? I suppose it probably does,
in which case extra calls can indeed hurt.
Yes, it does. Attached is a small test program.
The task-self, thread-self, host-self ports are special in that they have
specific mach_task_self, mach_thread_self, mach_host_self system calls
for retrieving send rights
