Messages in this thread |  | | | Date | Wed, 4 Dec 2002 16:18:39 -0800 (PST) | | From | Linus Torvalds <> | | Subject | Re: [PATCH] compatibility syscall layer (lets try again) |
| |
On Wed, 4 Dec 2002, Jim Houston wrote: > > Agreed! In my alternative version of the Posix timers patch, I avoid > calling do_signal() from clock_nanosleep by using a variant of the > existing ERESTARTNOHAND mechanism. The problem I ran into was that I > could not tell on entry to clock_nanosleep if it was a new call or > an old one being restarted.
Restarting has other problems too, namely how to save off the partial results.
> I solved this by adding a new > ERESTARTNANOSLP error code and making a small change in do_signal(). > The handling of ERESTARTNANOSLP is the same as ERESTARTNOHAND but also > sets a new flag in the task_struct before restarting the system call.
The problem I see with this is that the signal handler can do a "siglongjump()" out of the regular path, and the next system call may well be a _new_ nanosleep() that has nothing to do with the old one. And realizing that it's _not_ a restarted one is interesting.
A better and more flexible approach would be to not restart the same system call with the same parameters, but having some way of telling do_signal to restart with new parameters and a new system call number.
For example, it shouldn't be impossible to have an interface more akin to
... thread_info->restart_block.syscall = __NR_nanosleep_restart; thread_info->restart_block.arg0 = timeout + jiffies; /* absolute time */ return -ERESTARTSYS_RESTARTBLOCK; where the signal stack stuff re-writes not just eip (like the current restart logic does), but also rewrites the system call number and the argument registers.
This way you can get a truly restartable system call, because the arguments really need to be fundamentally changed (the restarted system call had better have _absolute_ time, not relative time, since we don't know how much time passed before it got restarted).
Linus
- 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/
|  |