Messages in this thread | | | Date | Tue, 10 Dec 2002 15:07:37 -0800 | From | george anzinger <> | Subject | Re: [PATCH] compatibility syscall layer (lets try again) |
| |
Daniel Jacobowitz wrote: > > On Fri, Dec 06, 2002 at 09:57:08AM -0800, Linus Torvalds wrote: > > > > I just pushed my version of the system call restart code to the BK trees. > > It's losely based on Georges code, but subtly different. Also, I didn't > > actually update any actual system calls to use it, I just did the > > infrastructure. > > > > Non-x86 architectures need to be updated to work with this: they need to > > update their thread structures, the additional do_signal() support in > > their signal.c, and add the actual system call itself somewhere. For x86, > > this was about 15 lines of changes. > > > > The basic premise is very simple: if you want to restart a system call, > > you can do > > > > restart = ¤t_thread()->restart_block; > > restart->fn = my_continuation_function; > > restart->arg0 = my_arg0_for_continuation; > > restart->arg1 = my_arg1_for_continuation; > > .. > > return -ERESTARTSYS_RESTARTBLOCK; > > > > which will cause the system call to either return -EINTR (if a signal > > handler was actually invoced) or for "benign" signals (SIGSTOP etc) it > > will end up restarting the system call at the continuation function (with > > the "restart" block as the argument). > > > > We could extend this to allow restarting even over signal handlers, but > > that would have some re-entrancy issues (ie what happens if a signal > > handler itself wants to use a system call that may want restarting), so at > > least for now restarting is only done when no handler is invoced (*). > > > > Linus > > > > (*) The nesting case is by no means impossible to handle gracefully > > (adding a "restart even if handler is called" error number and returning > > -EINTR if nesting, for example), but I don't know of any system calls that > > would really want to try to restart anyway, so.. > > Well, here's something to consider. This isn't entirely hypothetical; > there are test cases in GDB's regression suite that cover nearly this. > > Suppose a process is sleeping for an hour. The user wants to see what > another thread is doing, so he hits Control-C; the thread which happens > to be reported as 'current' is the one that was in nanosleep(). It > used to be that when he said continue, the nanosleep would return; now > hopefully it'll continue. Great! But this damnable user isn't done > yet. He wants to look at one of his data structures. He calls a > debugging print_foo() function from GDB. He realizes he left a > sleep-for-a-minute nanosleep call in it and C-c's again. Now we have > two interrupted nanosleep calls and the application will never see a > signal to interrupt either of them; he says "continue" twice and > expects to get back to his hour-long sleep. > > Note that I'm not saying we _need_ to support this, mind :) It's a > little pathological.
I seem to recall working on a debugger in the distant past and put a lock in it that did not allow it to run a debuggee function while the debugee was in a system call. It seems to me that is is begging for problems and is not that hard for gdb/etc to prevent.
Daniel, what to you think?
-g > > Another thing that annoys me slightly about this is that we mess with > the value in orig_eax etc. Now a debugger would have to look at the > instruction stream to figure out what the syscall was that we're > stopped in, reliably. Not a big deal. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |