Re: Q: PTRACE_ATTACH && -EINTR

[Oleg Nesterov]

On 06/08, Roland McGrath wrote:
>
> > It was renamed in -next. Should I send these fixes now for 2.6.20, or we can
> 								 30
> > wait for 2.6.31 ?
>
> IMHO they should go in ASAP since we know this is a regression just
> introduced in 2.6.29.  To me, the fact that nobody has noticed yet
> makes it more important not to delay--this new problem is so obscure
> that whoever is affected by it is likely to waste a lot of time figuring
> out what has started happening deep down in a huge pile of userland code.

2,6,30 is already released.

So, we need the trivial patch below, and perhaps a similar fix in
proc_pid_attr_write().

But giwen that ->cred_exec_mutex was renamed, I do not know where to send
this patch. This rename conflicts with ptrace changes in -mm, and the patch
below will add more confusion.

I'll wait until rename or -mm bits will be applied, then send this patch.
Fortunately the problem is not serious, ->cred_exec_mutex should be mostly
free.

Oleg.

--- T/fs/exec.c~	2009-05-24 21:46:20.000000000 +0200
+++ T/fs/exec.c	2009-06-10 14:58:27.000000000 +0200
@@ -1296,8 +1296,8 @@ int do_execve(char * filename,
 	if (!bprm)
 		goto out_files;
 
-	retval = mutex_lock_interruptible(&current->cred_exec_mutex);
-	if (retval < 0)
+	retval = -ERESTARTNOINTR;
+	if (mutex_lock_interruptible(&current->cred_exec_mutex))
 		goto out_free;
 	current->in_execve = 1;
 
--- T/kernel/ptrace.c~	2009-06-10 14:46:57.000000000 +0200
+++ T/kernel/ptrace.c	2009-06-10 14:54:24.000000000 +0200
@@ -189,8 +189,8 @@ int ptrace_attach(struct task_struct *ta
 	 * Protect exec's credential calculations against our interference;
 	 * SUID, SGID and LSM creds get determined differently under ptrace.
 	 */
-	retval = mutex_lock_interruptible(&task->cred_exec_mutex);
-	if (retval < 0)
+	retval = -ERESTARTNOINTR;
+	if (mutex_lock_interruptible(&task->cred_exec_mutex))
 		goto out;
 
 	task_lock(task);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/