How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD)

How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD)

Post by Russell Kin » Fri, 24 Aug 2001 03:50:07




> Uh..?  I though that was what I was allowing.  It seems to me to be a
> lot of extra work to put the same code in 15 different archs.
> Especially if one does not really know each of them, nor can any one
> group (or individual) be expected to be able to test (or even have the
> hardware to test) each of them.

Umm, my best advice is to look at sys_fork() and do_fork(), sys_execve()
and do_execve().

--

             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD)

Post by george anzinge » Sat, 25 Aug 2001 06:20:10




> > Sorry, but none of those system calls requires the registers which is
> > where the problem is.

> /* Fork a new task - this creates a new program thread.
>  * This is called indirectly via a small wrapper
>  */
> asmlinkage int sys_fork(struct pt_regs *regs)
>                         ^^^^^^^^^^^^^^^^^^^^
> {
>         return do_fork(SIGCHLD, regs->ARM_sp, regs, 0);
> }

> /* sys_execve() executes a new program.
>  * This is called indirectly via a small wrapper
>  */
> asmlinkage int
> sys_execve(char *filenamei, char **argv, char **envp, struct pt_regs *regs)
>                                                      ^^^^^^^^^^^^^^^^^^^^^
> {
>         int error;
>         char * filename;

>         filename = getname(filenamei);
>         error = PTR_ERR(filename);
>         if (IS_ERR(filename))
>                 goto out;
>         error = do_execve(filename, argv, envp, regs);
>         putname(filename);
> out:
>         return error;
> }

> Certainly looks to me like they do.  See the highlighted arguments.

I stand corrected!  Guess I should look before I leap, uh email.  OK,
here is the issue I am dealing with.  I would like to define a new
system call  (clock_nanosleep()) to conform to the extended POSIX
standard.  It, as well as the current nanosleep() needs the regs. to
call do_signal(), however, it is strictly a pass thru, do_signal() uses
the regs, not the main body of the sleep functions.  The various
platforms have different ways of passing the regs to the system call and
also different ways of calling do_signal().  The failure to be able to
call do_signal() results in the call not properly ignoring ptrace
signals, see the beginning of this thread.  What I would like to do is
to abstract the interface to the system calls (just the nanosleep ones
will do for now) so that the common code will work (except for the
ptrace problem) while leaving room for the platform code to pick up the
ball as they support people feel so inclined.  This means that some of
them would have to write the required wrappers and all would have to
define the macros that abstract the interface.  Here is what I have so
far:

In include/linux/signal.h
#ifndef PT_REGS_ENTRY
#define PT_REGS_ENTRY(type,name,p1_type,p1,p2_type,p2) \
type name(pi_type p1,p2_type,p2) {

#define _do_signal() 1
#endif

In include/asm_i386/signal.h

asmlinkage int FASTCALL(do_signal(struct pt_regs *regs, sigset_t
*oldset));
#define PT_REGS_ENTRY(type,name,p1_type,p1,p2_type,p2) \
type name(p1_type p1,p2_type p2) \
{       struct pt_regs *regs=(struct pt_regs *)&p1;
#define _do_signal() do_signal(regs,NULL)

and in kernel/timer.c

PT_REGS_ENTRY(asmlinkage long,sys_nanosleep,struct timespec*,rqtp,struct
timespec* ,rmtp)
struct timespec t;.....

do{
        current->state = TASK_INTERRUPTABLE;

Quote:}while((expire = schedule_timeout(expire)) && !_do_signal());

I think this lets us get on with fixing the i386 branch without breaking
any other branch and still leaves it easy for other branches to catch up
as they find the time to do so.

The question I haven't had time to research is if there is enough
flexibility for all the other platforms.  Certainly ARM can insert the
additional parameter in the system call using this.  

If you want my $.02 worth, the pt_regs should be addressable without
reference to the call stack.  To the best of my knowledge, they are
always at the base of the kernel stack (assuming we ignore the case of
kernel interrupts where we don't allow signal delivery in any case) and
so should be find able by doing a bit of math on the stack pointer.  How
does the hardware come up with a stack pointer when interrupting/
calling from user space?  Food for thought, and of course, it is
different for each platform.

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. ptrace(), fork(), sleep(), exit(), SIGCHLD

Hi,
    The following program behaves incorrectly when traced:

  $ uname -a
  Linux dependo 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i686 unknown
  $ cc -v
  Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
  gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
  $ strace -V
  strace -- version 4.2
  $ cat t.c
  main()
  {
        switch (fork())
        {
        case -1:
                write(2, "fork\n", 5);
                break;

        case 0:
                usleep(1000000);
                break;

        default:
                if (usleep(5000000) == -1)
                        write(2, "wrong\n", 6);
                break;
        }

        exit(0);
  }
  $ cc t.c
  $ time ./a.out

  real    0m5.011s
  user    0m0.000s
  sys     0m0.000s
  $ time strace -o /dev/null ./a.out
  wrong

  real    0m1.025s
  user    0m0.010s
  sys     0m0.010s
  $

The problem appears to be that, when traced, the child process' exit()
interrupts the parent's usleep() with a SIGCHLD, the latter returning EINTR.
It also fails in the same way under Linux 2.2.16 and 2.2.19.

What am I missing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. What is bdflush??

3. This clone thing...am I stupid, or am I right?

4. Upgrade of AIX on RS6000 Powerstation model 370 with no CDROM

5. dazed & confused

6. I am with the following error, when i am running lilo...

7. How can I disable an user account on HP-UX B.10.20?

8. Am I touchy? Or am I right?

9. Am I seeing IPv5, or am I hallucinating?

10. I am buying an Ultra 5 but am lost in part numbers ....

11. I am in text mode, what browser am I running....

12. I am si**y am I?