Messages in this thread Patch in this message | | | Date | Wed, 10 Jun 2009 15:11:16 +0200 | From | Oleg Nesterov <> | Subject | Re: Q: PTRACE_ATTACH && -EINTR |
| |
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(¤t->cred_exec_mutex); - if (retval < 0) + retval = -ERESTARTNOINTR; + if (mutex_lock_interruptible(¤t->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);
| |