You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Doug R. <df...@nl...> - 2004-01-16 09:51:50
|
On Fri, 2004-01-16 at 01:57, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-15 at 12:16, Doug Rabson wrote: > > Yes, I'm aware of the internal signal thing and I left that alone apart > > from using pthread_kill to direct them to the proxy thread. It seems to > > me that VKI_SIGVGKILL might not be needed since pthread_cancel should be > > roughly equivalent. > > Yes, but I'm concerned about getting entangled in the internal details > of how the pthreads implementation handles pthread_cancel. True. > > > Yes. Of the two pthread implementations I tested, one overrides all the > > signal calls to help it implement its many user threads to few kernel > > threads policy. > > OK, but presumably that pthread implementation is unusable to us, since > directly calling int 0x80 from a thread will potentially deadlock the > threads library. We would need to make sure that each proxy gets its > own kernel-level schedulable entity when we actually try to run a > syscall. This happens automatically in the FreeBSD kernel. When a thread blocks in the kernel, an upcall to the userland thread scheduler happens and it switches to the next runnable thread. It was an interesting exercise putting together a pthread proxylwp implementation but its certainly not the right solution for some systems. For example on FreeBSD 4.x there is no decent support for kernel threads and the userland threading library relies on intercepting all the blocking syscalls and using poll(2) in the thread scheduler to attempt to switch threads when they would block. > > > > One possibility is to fully virtualize the client's FDs with a mapping > > > table. That means we need to be able to intercept all ways in which the > > > client and the kernel can refer to FDs to each other. For plain old > > > read/write/open/close that's pretty simple, but mucking about with > > > poll/select sets is a bit hairy and I'm a bit concerned about things > > > like ioctls which can generate new FDs by unconventional means. > > > > That would work pretty well in most cases. I don't think there can be > > many weird ways for ioctls to generate new FDs. We need to handle them > > all for proper fd leak checking anyway. > > Yes, but leak checking doesn't need to be completely correct - the > penalty for getting it a bit wrong is just that we give less good errors > for that case. If we fully virtualize FDs, then we have to be 100% > correct. Very true. > > > I was just reading about that yesterday on The Register. I've used the > > hardware ia32 emulation on Itanium 1 early hardware and it sucks big > > time. Software is likely to be lots faster. > > ...and then we have the fun of multiple layers of dynamic compilation... No no, stop it. VMware running bochs running valgrind translating an ia64 implementation of gdb simulating a mips64. |
|
From: Eyal L. <ey...@ey...> - 2004-01-16 07:51:27
|
Julian Seward wrote: > > On Thursday 15 January 2004 08:57, Robert Walsh wrote: > > > However, the same sort of malloc() followed by a free() was > > > done a number of times earlier. If vg holds on to freed > > > memory then there may be a problem. The machine is 1GB memory > > > and 2GB swap and abour 450MB of swap was used at the time > > > of failure. > > > > Valgrind does hold on to memory for a certain length of time after it's > > been freed. This is to catch things like this: > > > > x = malloc(10); > > free(x); > > y = malloc(10); > > *x = 0; > > > > If the second malloc happed to return the same value as the first, the > > invalid write to *x would never be caught. > > > > However, it doesn't keep these forever, and I had assumed it would use > > that pool when it ran out of memory. Hmm. Too tired to look at the > > code now, but it's in there somewhere. Search for freed_list. > > Command-line parameter: > --freelist-vol=<number> volume of freed blocks queue [1000000] Used '--freelist-vol=0' - no change. Furthermore, since I know the failure is in a malloc that never returns, I put a sleep(2) just before the malloc and started a 'vmstat 1'. It fails in the same way and only under 400MB of swap (out of 2GB) is used max. Is there any other tracing I can turn on to help diagnose the problem? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Jeremy F. <je...@go...> - 2004-01-16 05:38:24
|
CVS commit by fitzhardinge: Oops, add missing file. A exec-sigmask.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] |
|
From: Jeremy F. <je...@go...> - 2004-01-16 02:20:26
|
CVS commit by fitzhardinge: Add other .exp file for exec-sigmask. A exec-sigmask.stdout.exp 1.1 |
|
From: Jeremy F. <je...@go...> - 2004-01-16 02:19:26
|
CVS commit by fitzhardinge:
Fix bug 72484. Set the process signal mask to match the client's before
running exec.
A none/tests/exec-sigmask.stderr.exp 1.1
M +2 -2 coregrind/vg_include.h 1.169
M +23 -0 coregrind/vg_syscalls.c 1.78
M +4 -1 none/tests/Makefile.am 1.21
--- valgrind/none/tests/Makefile.am #1.20:1.21
@@ -16,4 +16,6 @@
discard.stderr.exp discard.stdout.exp \
discard.vgtest \
+ exec-sigmask.vgtest
+ exec-sigmask.stdout.exp exec-sigmask.stderr.exp \
floored.stderr.exp floored.stdout.exp \
floored.vgtest \
@@ -45,5 +47,5 @@
check_PROGRAMS = \
args bitfield1 bt_everything bt_literal coolo_strlen \
- cpuid dastest discard floored fork fpu_lazy_eflags \
+ cpuid dastest discard exec-sigmask floored fork fpu_lazy_eflags \
fucomip munmap_exe map_unmap mremap rcl_assert \
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
@@ -64,4 +66,5 @@
dastest_SOURCES = dastest_c.c dastest_s.s
discard_SOURCES = discard.c
+exec_sigmask_SOURCES = exec-sigmask.c
fork_SOURCES = fork.c
floored_SOURCES = floored.c
--- valgrind/coregrind/vg_syscalls.c #1.77:1.78
@@ -1878,4 +1878,27 @@ PRE(execve)
}
+ /* Set our real sigmask to match the client's sigmask so that the
+ exec'd child will get the right mask. First we need to clear
+ out any pending signals so they they don't get delivered, which
+ would confuse things.
+
+ XXX This is a bug - the signals should remain pending, and be
+ delivered to the new process after exec. There's also a
+ race-condition, since if someone delivers us a signal between
+ the sigprocmask and the execve, we'll still get the signal. Oh
+ well.
+ */
+ {
+ vki_ksigset_t allsigs;
+ vki_ksiginfo_t info;
+ static const struct vki_timespec zero = { 0, 0 };
+
+ VG_(ksigfillset)(&allsigs);
+ while(VG_(ksigtimedwait)(&allsigs, &info, &zero) > 0)
+ ;
+
+ VG_(ksigprocmask)(VKI_SIG_SETMASK, &tst->sig_mask, NULL);
+ }
+
res = VG_(do_syscall)(__NR_execve, arg1, arg2, arg3);
--- valgrind/coregrind/vg_include.h #1.168:1.169
@@ -765,6 +765,6 @@ typedef
vki_ksigset_t sig_mask;
- /* Effective signal mask. This is the mask which is currently
- applying; it may be different from sig_mask while a signal
+ /* Effective signal mask. This is the mask which currently
+ applies; it may be different from sig_mask while a signal
handler is running.
*/
|
|
From: Jeremy F. <je...@go...> - 2004-01-16 02:16:19
|
CVS commit by fitzhardinge:
Fix bug 72650. Only restart syscalls on signal if the client asked for it.
A none/tests/syscall-restart1.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A none/tests/syscall-restart1.stderr.exp 1.1
A none/tests/syscall-restart1.stdout.exp 1.1
A none/tests/syscall-restart1.vgtest 1.1
A none/tests/syscall-restart2.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A none/tests/syscall-restart2.stderr.exp 1.1
A none/tests/syscall-restart2.stdout.exp 1.1
A none/tests/syscall-restart2.vgtest 1.1
M +2 -2 coregrind/vg_include.h 1.168
M +13 -13 coregrind/vg_proxylwp.c 1.12
M +1 -1 coregrind/vg_scheduler.c 1.136
M +5 -15 coregrind/vg_signals.c 1.57
M +37 -18 coregrind/vg_syscalls.c 1.77
M +5 -0 none/tests/Makefile.am 1.20
--- valgrind/none/tests/Makefile.am #1.19:1.20
@@ -39,4 +39,6 @@
shorts.stderr.exp shorts.vgtest \
smc1.stderr.exp smc1.stdout.exp smc1.vgtest \
+ syscall-restart1.vgtest syscall-restart1.stdout.exp syscall-restart1.stderr.exp \
+ syscall-restart2.vgtest syscall-restart2.stdout.exp syscall-restart2.stderr.exp \
yield.stdout.exp yield.vgtest
@@ -47,4 +49,5 @@
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
pth_blockedsig \
+ syscall-restart1 syscall-restart2 \
coolo_sigaction gxx304 yield
@@ -78,4 +81,6 @@
shortpush_SOURCES = shortpush.c
shorts_SOURCES = shorts.c
+syscall_restart1_SOURCES = syscall-restart1.c
+syscall_restart2_SOURCES = syscall-restart2.c
yield_SOURCES = yield.c
yield_LDADD = -lpthread
--- valgrind/coregrind/vg_proxylwp.c #1.11:1.12
@@ -181,5 +181,5 @@ struct ProxyLWP {
};
-static void sys_wait_results(Bool block, ThreadId tid, enum RequestType reqtype);
+static void sys_wait_results(Bool block, ThreadId tid, enum RequestType reqtype, Bool restart);
struct PX_Request {
@@ -842,7 +842,7 @@ void VG_(proxy_sendsig)(ThreadId tid, In
syscall to dinish. */
if (tst->status == VgTs_WaitSys && tst->syscallno == __NR_rt_sigtimedwait)
- sys_wait_results(True, tid, PX_RunSyscall);
+ sys_wait_results(True, tid, PX_RunSyscall, True);
else
- sys_wait_results(True, tid, PX_Signal);
+ sys_wait_results(True, tid, PX_Signal, True);
}
}
@@ -867,5 +867,5 @@ void VG_(proxy_abort_syscall)(ThreadId t
VG_(ktkill)(lwp, VKI_SIGVGINT);
- sys_wait_results(True, tid, PX_RunSyscall);
+ sys_wait_results(True, tid, PX_RunSyscall, False);
vg_assert(tst->status == VgTs_Runnable);
@@ -1064,5 +1064,5 @@ void VG_(proxy_delete)(ThreadId tid, Boo
may be blocked writing to it, causing a deadlock with us as we
wait for it to exit. */
- sys_wait_results(True, tid, PX_Exiting);
+ sys_wait_results(True, tid, PX_Exiting, True);
res = proxy_wait(proxy, True, &status);
@@ -1092,5 +1092,5 @@ void VG_(proxy_delete)(ThreadId tid, Boo
wait for a reply for that particular tid.
*/
-static void sys_wait_results(Bool block, ThreadId tid, enum RequestType reqtype)
+static void sys_wait_results(Bool block, ThreadId tid, enum RequestType reqtype, Bool restart)
{
Bool found_reply = (reqtype == PX_BAD);
@@ -1154,5 +1154,5 @@ static void sys_wait_results(Bool block,
vg_assert(tst->status == VgTs_WaitSys);
- VG_(post_syscall)(res.tid);
+ VG_(post_syscall)(res.tid, restart);
break;
@@ -1188,8 +1188,8 @@ static void sys_wait_results(Bool block,
void VG_(proxy_results)(void)
{
- sys_wait_results(False, 0, PX_BAD);
+ sys_wait_results(False, 0, PX_BAD, True);
}
-void VG_(proxy_wait_sys)(ThreadId tid)
+void VG_(proxy_wait_sys)(ThreadId tid, Bool restart)
{
ThreadState *tst = VG_(get_ThreadState)(tid);
@@ -1197,5 +1197,5 @@ void VG_(proxy_wait_sys)(ThreadId tid)
vg_assert(tst->status == VgTs_WaitSys);
- sys_wait_results(True, tid, PX_RunSyscall);
+ sys_wait_results(True, tid, PX_RunSyscall, restart);
}
@@ -1227,5 +1227,5 @@ void VG_(proxy_setsigmask)(ThreadId tid)
updates their signal masks, A's update must be done before B's
is). */
- sys_wait_results(True, tid, PX_SetSigmask);
+ sys_wait_results(True, tid, PX_SetSigmask, True);
}
@@ -1272,5 +1272,5 @@ void VG_(proxy_waitsig)(void)
VG_(route_signals)();
else
- sys_wait_results(True, VG_INVALID_THREADID /* any */, PX_Signal);
+ sys_wait_results(True, VG_INVALID_THREADID /* any */, PX_Signal, True);
}
@@ -1365,5 +1365,5 @@ void VG_(proxy_sanity)(void)
sane = False;
}
- sys_wait_results(True, tid, PX_Ping);
+ sys_wait_results(True, tid, PX_Ping, True);
/* Can't make an assertion here, fortunately; this will
either come back or it won't. */
--- valgrind/coregrind/vg_signals.c #1.56:1.57
@@ -1448,20 +1448,10 @@ void VG_(deliver_signal) ( ThreadId tid,
results right now, so wait for them to appear. This makes
the thread runnable again, so we're in the right state to run
- the handler, and resume the syscall when we're done. */
- VG_(proxy_wait_sys)(tid);
-
+ the handler. We ask post_syscall to restart based on the
+ client's sigaction flags. */
if (0)
- VG_(printf)("signal %d interrupting syscall %d\n",
- sigNo, tst->syscallno);
-
- if (tst->m_eax == -VKI_ERESTARTSYS) {
- if (handler->scss_flags & VKI_SA_RESTART) {
- VG_(restart_syscall)(tid);
- } else
- tst->m_eax = -VKI_EINTR;
- } else {
- /* return value is already in eax - either EINTR or the
- normal return value */
- }
+ VG_(printf)("signal %d interrupted syscall %d; restart=%d\n",
+ sigNo, tst->syscallno, !!(handler->scss_flags & VKI_SA_RESTART));
+ VG_(proxy_wait_sys)(tid, !!(handler->scss_flags & VKI_SA_RESTART));
}
--- valgrind/coregrind/vg_include.h #1.167:1.168
@@ -1608,5 +1608,5 @@ extern void VG_(proxy_sigack) ( Thread
extern void VG_(proxy_abort_syscall) ( ThreadId tid );
extern void VG_(proxy_waitsig) ( void );
-extern void VG_(proxy_wait_sys) (ThreadId tid);
+extern void VG_(proxy_wait_sys) (ThreadId tid, Bool restart);
extern void VG_(proxy_shutdown) ( void ); /* shut down the syscall workers */
@@ -1631,5 +1631,5 @@ extern Char *VG_(resolve_filename)(Int f
extern Bool VG_(pre_syscall) ( ThreadId tid );
-extern void VG_(post_syscall)( ThreadId tid );
+extern void VG_(post_syscall)( ThreadId tid, Bool restart );
extern void VG_(restart_syscall) ( ThreadId tid );
--- valgrind/coregrind/vg_scheduler.c #1.135:1.136
@@ -700,5 +700,5 @@ void sched_do_syscall ( ThreadId tid )
/* If pre_syscall returns true, then we're done immediately */
if (VG_(pre_syscall)(tid)) {
- VG_(post_syscall(tid));
+ VG_(post_syscall(tid, True));
vg_assert(VG_(threads)[tid].status == VgTs_Runnable);
} else {
--- valgrind/coregrind/vg_syscalls.c #1.76:1.77
@@ -5243,5 +5243,5 @@ Bool VG_(pre_syscall) ( ThreadId tid )
-void VG_(post_syscall) ( ThreadId tid )
+void VG_(post_syscall) ( ThreadId tid, Bool restart )
{
ThreadState* tst;
@@ -5249,4 +5249,5 @@ void VG_(post_syscall) ( ThreadId tid )
const struct sys_info *sys;
Bool special = False;
+ Bool restarted = False;
void *pre_res;
@@ -5273,8 +5274,34 @@ void VG_(post_syscall) ( ThreadId tid )
}
+ if (tst->m_eax == -VKI_ERESTARTSYS) {
+ /* Applications never expect to see this, so we should either
+ restart the syscall or fail it with EINTR, depending on what
+ our caller wants. Generally they'll want to restart, but if
+ client set the signal state to not restart, then we fail with
+ EINTR. Either way, ERESTARTSYS means the syscall made no
+ progress, and so can be failed or restarted without
+ consequence. */
+ if (0)
+ VG_(printf)("syscall %d returned ERESTARTSYS; restart=%d\n",
+ syscallno, restart);
+
+ if (restart) {
+ restarted = True;
+ VG_(restart_syscall)(tid);
+ } else
+ tst->m_eax = -VKI_EINTR;
+ }
+
+ if (!restarted) {
if (!VG_(is_kerror)(tst->m_eax) && sys->after != NULL)
(sys->after)(tst->tid, tst);
- /* Do any post-syscall actions */
+ /* Do any post-syscall actions
+
+ NOTE: this is only called if the syscall completed. If the
+ syscall was restarted, then it will call the Tool's
+ pre_syscall again, without calling post_syscall (ie, more
+ pre's than post's)
+ */
if (VG_(needs).syscall_wrapper) {
VGP_PUSHCC(VgpSkinSysWrap);
@@ -5282,16 +5309,8 @@ void VG_(post_syscall) ( ThreadId tid )
VGP_POPCC(VgpSkinSysWrap);
}
-
- if (tst->m_eax == -VKI_ERESTARTSYS) {
- /* Applications never expect to see this, so we should actually
- restart the syscall (it means the signal happened before the
- syscall made any progress, so we can safely restart it and
- pretend the signal happened before the syscall even
- started) */
- VG_(restart_syscall)(tid);
}
tst->status = VgTs_Runnable; /* runnable again */
- tst->syscallno = -1;
+ tst->syscallno = -1; /* no current syscall */
VGP_POPCC(VgpCoreSysWrap);
|
|
From: Jeremy F. <je...@go...> - 2004-01-16 01:59:45
|
On Thu, 2004-01-15 at 12:16, Doug Rabson wrote: > Yes, I'm aware of the internal signal thing and I left that alone apart > from using pthread_kill to direct them to the proxy thread. It seems to > me that VKI_SIGVGKILL might not be needed since pthread_cancel should be > roughly equivalent. Yes, but I'm concerned about getting entangled in the internal details of how the pthreads implementation handles pthread_cancel. > Yes. Of the two pthread implementations I tested, one overrides all the > signal calls to help it implement its many user threads to few kernel > threads policy. OK, but presumably that pthread implementation is unusable to us, since directly calling int 0x80 from a thread will potentially deadlock the threads library. We would need to make sure that each proxy gets its own kernel-level schedulable entity when we actually try to run a syscall. > > One possibility is to fully virtualize the client's FDs with a mapping > > table. That means we need to be able to intercept all ways in which the > > client and the kernel can refer to FDs to each other. For plain old > > read/write/open/close that's pretty simple, but mucking about with > > poll/select sets is a bit hairy and I'm a bit concerned about things > > like ioctls which can generate new FDs by unconventional means. > > That would work pretty well in most cases. I don't think there can be > many weird ways for ioctls to generate new FDs. We need to handle them > all for proper fd leak checking anyway. Yes, but leak checking doesn't need to be completely correct - the penalty for getting it a bit wrong is just that we give less good errors for that case. If we fully virtualize FDs, then we have to be 100% correct. > I was just reading about that yesterday on The Register. I've used the > hardware ia32 emulation on Itanium 1 early hardware and it sucks big > time. Software is likely to be lots faster. ...and then we have the fun of multiple layers of dynamic compilation... J |