Problem: strace -ff fails on 2.4.21-rc1

I can now strace minicom and its children with 2.4.21-rc2-ac1 but it
hangs on exit. Both child processes exit successfully:

 # tail -5 minicom.trc.5775

10:16:49.299253 kill(5774, SIG_0) = 0
10:16:49.299418 unlink("/var/lock/LOCKDEV") = 0

10:16:49.299649 close(3)                = 0
10:16:49.299849 umask(022)              = 02
10:16:49.300043 _exit(0)                = ?

 # tail -8 minicom.trc.5776

10:17:05.497676 kill(5774, SIG_0) = 0
10:17:05.497845 unlink("/var/lock/LCK...5774") = 0 10:17:05.498068 unlink("/var/lock/LCK..ttyS1") = 0 10:17:05.498283 unlink("/var/lock/LCK.004.065") = 0 10:17:05.498616 unlink("/var/lock/LOCKDEV") = 0

10:17:05.498870 close(4)                = 0
10:17:05.499065 umask(022)              = 02
10:17:05.499337 _exit(0)                = ?

However strace and minicom are hung up somehow and the screen is black with a blinking cursor at row 1 column 1. The other ttys all work OK and killing minicom cleans everything up.

 # tail -3 minicom.trc

10:17:05.499678 --- SIGCHLD (Child exited) --- 10:17:05.499760 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_IGN}, 8) = 0 10:17:05.499971 close(3

strace S C015FF82 960 5773 822 5774 (NOTLB)

Call Trace:    [<c015ff82>] [<c011dba8>] [<c0108b73>]
minicom       S 00000000  2400  5774   5773                     (NOTLB)
Call Trace:    [<c0122f24>] [<c0124095>] [<c021195b>] [<c0220d79>] [<c020d997>]
  [<c0124095>] [<c0124159>] [<c020e01a>] [<c013c52e>] [<c01183a1>] [<c013b1d5>]
  [<c013b23b>] [<c0108bdf>]

Proc; strace

Trace; c015ff82 <ext3_file_write+22/b0>
Trace; c011dba8 <sys_wait4+3c8/400>
Trace; c0108b73 <system_call+33/38>
Proc; minicom

Trace; c0122f24 <schedule_timeout+14/a0>
Trace; c0124095 <wake_up_parent+25/40>
Trace; c021195b <tty_wait_until_sent+9b/e0>
Trace; c0220d79 <rs_close+129/1f0>
Trace; c020d997 <release_dev+247/500>
Trace; c0124095 <wake_up_parent+25/40>
Trace; c0124159 <do_notify_parent+a9/c0>
Trace; c020e01a <tty_release+2a/60>
Trace; c013c52e <fput+4e/100>
Trace; c01183a1 <schedule+351/3b0>
Trace; c013b1d5 <filp_close+95/a0>
Trace; c013b23b <sys_close+5b/70>
Trace; c0108bdf <tracesys+1f/23>

Configuration:
2.4.21-rc2-ac1
SMP kernel on 1-CPU SMP machine (PII Xeon, 440GX)

To reproduce:

        # strace -ff -q -tt -o minicom.trc minicom

Note:

        I also get lockups while minicom is running:

        Proc;  strace
        >>EIP; c015ff82 <ext3_file_write+22/b0>   <=====
        Trace; c015ff82 <ext3_file_write+22/b0>
        Trace; c011dba8 <sys_wait4+3c8/400>
        Trace; c0108b73 <system_call+33/38>
        Proc;  minicom
        >>EIP; 00000000 Before first symbol
        Trace; c0122f24 <schedule_timeout+14/a0>
        Trace; c021105a <read_chan+37a/720>
        Trace; c020cf5f <tty_read+cf/120>
        Trace; c013b706 <sys_read+96/110>
        Trace; c0108bdf <tracesys+1f/23>

Very strange, does this work with 2.4.20? What's your version of strace?

Hm, this sounds like there could be some error/loop opening the device, which could be the effect of another side effect of the original ptrace fix, which my fixes which are included in 2.4.21-rc2 don't fix.

This side effect causes that if a system call needs a module loaded, it is not loaded and only an error from request_module() is sent to the kernel log. The attached patch on top of 2.4.21-rc2, fixes this remaining problem.

I'm not writing much info about it now, except that I think that it does not open any securiy hole, but I would like to give it a little more testing on SMP machines. On single CPU it fixed the "modprobe rejected" problem fine for me, without sacrifying ptrace securitey.

I'm uncertain if it would help in your case.

Very strange, maybe a "tail minicom.trc.*" at the time when it's hanging helps to get some idea.

Another note: suid is ignored when you are tracing the task which runs exec() for a setuid program.

So if minicom relies on having the setgid gid of /sbin/lockdev honored has in your case, the only ways I can find to get it working inder strace are:

- Change the locking config (temporary, for the debug) so that /sbin/lockdev does not need to be setgid.

- Don't have ptrace follow fork mode activated when forking the child which exec()'s /sbin/lockdev.

Bernd

@@ -572,21 +572,13 @@
 	unsigned old_task_dumpable;
 	long ret;
 
-	/* lock out any potential ptracer */
-	task_lock(task);
-	if (task->ptrace) {
-		task_unlock(task);
-		return -EPERM;
-	}
-
-	old_task_dumpable = task->task_dumpable;
+	/* lock out any potential ptracer for the new task_struct copy */
 	task->task_dumpable = 0;
-	task_unlock(task);
 
 	ret = arch_kernel_thread(fn, arg, flags);
 
 	/* never reached in child process, only in parent */
-	current->task_dumpable = old_task_dumpable;
+	task->task_dumpable = old_task_dumpable;
 
 	return ret;
 }

Run strace as root, and use strace -u? Then it should not remove the setuid-ness, I think.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer