linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).