lkml.org 
[lkml]   [2002]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:1.338 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site