From: Jim Houston <jim.houston@ccur.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: george anzinger <george@mvista.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
LKML <linux-kernel@vger.kernel.org>,
anton@samba.org, "David S. Miller" <davem@redhat.com>,
ak@muc.de, davidm@hpl.hp.com, schwidefsky@de.ibm.com,
ralf@gnu.org, willy@debian.org
Subject: Re: [PATCH] compatibility syscall layer (lets try again)
Date: Wed, 04 Dec 2002 21:27:55 -0500 [thread overview]
Message-ID: <3DEEB9AB.2A36454E@ccur.com> (raw)
In-Reply-To: Pine.LNX.4.44.0212041600070.3100-100000@home.transmeta.com
Linus Torvalds wrote:
>
> 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
Hi Linus,
The general solution you propose sounds nice but I have a feeling
the implementation would get ugly. It is hard enough to back up the
pc. I hate to think where the arguments are on some machines.
I think that "siglongjump()" is not a problem. My change to
do_signal() only sets the flag indicating a restart at the same time
it backs up the pc to restart the system call. I don't see a path
where the user code gets control before we're back at clock_nanosleep.
I'm saving the information to restart the nanosleep in the task_struct.
I have a pre-allocated timer which I leave running. When I get
into nanosleep for the restart, I just have to check if the timer has
already expired and, if not, go back to sleep. To calculate the
remaining time I also save an un-rounded copy of the absolute expiry
time (also in the task_struct).
Jim Houston - Concurrent Computer Corp.
next prev parent reply other threads:[~2002-12-05 2:20 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 7:02 [PATCH] compatibility syscall layer (lets try again) Stephen Rothwell
2002-12-04 7:07 ` [PATCH] compatibility syscall layer - PPC64 Stephen Rothwell
2002-12-06 23:03 ` Anton Blanchard
2002-12-04 7:16 ` [PATCH] compatibility syscall layer - SPARC64 Stephen Rothwell
2002-12-04 7:18 ` [PATCH] compatibility syscall layer - X86_64 Stephen Rothwell
2002-12-04 11:29 ` Andi Kleen
2002-12-04 7:26 ` [PATCH] compatibility syscall layer - IA64 Stephen Rothwell
2002-12-04 7:37 ` David Mosberger
2002-12-04 7:28 ` [PATCH] compatibility syscall layer (lets try again) Stephen Rothwell
2002-12-04 7:29 ` [PATCH] compatibility syscall layer - PARISC Stephen Rothwell
2002-12-04 7:30 ` [PATCH] compatibility syscall layer (lets try again) Stephen Rothwell
2002-12-04 7:33 ` Stephen Rothwell
2002-12-04 11:57 ` Pavel Machek
2002-12-04 16:54 ` Linus Torvalds
2002-12-04 16:54 ` David S. Miller
2002-12-04 17:05 ` Linus Torvalds
2002-12-04 19:56 ` george anzinger
2002-12-04 20:07 ` Linus Torvalds
2002-12-04 20:56 ` Daniel Jacobowitz
2002-12-04 22:09 ` David S. Miller
2002-12-04 22:31 ` george anzinger
2002-12-04 22:39 ` David S. Miller
2002-12-04 22:42 ` Linus Torvalds
2002-12-04 23:42 ` Jim Houston
2002-12-05 0:18 ` Linus Torvalds
2002-12-05 2:01 ` george anzinger
2002-12-05 2:51 ` Linus Torvalds
2002-12-05 3:10 ` Andi Kleen
2002-12-05 3:46 ` george anzinger
2002-12-05 4:11 ` Linus Torvalds
2002-12-05 7:10 ` george anzinger
2002-12-05 9:48 ` george anzinger
2002-12-05 15:24 ` Jim Houston
2002-12-05 16:35 ` george anzinger
2002-12-06 0:03 ` Richard Henderson
2002-12-05 17:03 ` Linus Torvalds
2002-12-06 9:17 ` george anzinger
2002-12-06 17:57 ` Linus Torvalds
2002-12-06 19:20 ` Linus Torvalds
2002-12-06 20:09 ` [PATCH] compatibility syscall layer (let's " Jim Houston
2002-12-06 20:33 ` george anzinger
2002-12-06 20:18 ` [PATCH] compatibility syscall layer (lets " george anzinger
2002-12-06 21:12 ` Linus Torvalds
2002-12-06 21:56 ` Jim Houston
2002-12-06 22:58 ` Linus Torvalds
2002-12-07 2:25 ` george anzinger
2002-12-06 23:08 ` george anzinger
2002-12-08 20:41 ` David S. Miller
2002-12-09 6:18 ` Stephen Rothwell
2002-12-09 15:41 ` Daniel Jacobowitz
2002-12-09 16:48 ` Linus Torvalds
2002-12-09 17:27 ` David Mosberger
2002-12-09 20:22 ` David S. Miller
2002-12-09 17:49 ` Jim Houston
2002-12-09 17:57 ` Linus Torvalds
2002-12-09 23:30 ` Paul Mackerras
2002-12-10 23:07 ` george anzinger
2002-12-11 7:10 ` Daniel Jacobowitz
2002-12-11 8:11 ` george anzinger
2002-12-11 8:26 ` Daniel Jacobowitz
2002-12-10 11:08 ` Jamie Lokier
2002-12-05 2:27 ` Jim Houston [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-09 16:58 Mikael Starvik
2002-12-09 17:35 ` Linus Torvalds
2002-12-09 18:46 ` David Mosberger
2002-12-10 0:13 ` Paul Mackerras
2002-12-10 23:11 ` george anzinger
2002-12-09 17:16 Martin Schwidefsky
2002-12-09 17:33 ` Linus Torvalds
2002-12-09 20:18 ` David S. Miller
2002-12-09 17:56 Martin Schwidefsky
2002-12-09 18:20 ` Linus Torvalds
2002-12-10 14:40 ` Keith Owens
2002-12-09 18:41 Martin Schwidefsky
2002-12-09 18:52 ` Linus Torvalds
2002-12-10 8:20 ` george anzinger
2002-12-10 8:42 Martin Schwidefsky
2002-12-10 17:17 Martin Schwidefsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DEEB9AB.2A36454E@ccur.com \
--to=jim.houston@ccur.com \
--cc=ak@muc.de \
--cc=anton@samba.org \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@gnu.org \
--cc=schwidefsky@de.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@transmeta.com \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.