Re: [PATCH] do_wait fix for 2.6.10-rc1

From: Linus Torvalds
Date: Mon Nov 08 2004 - 20:19:57 EST




Ok, I haven't gotten any response on this one, but I'm running it in my
tree, and look as I might, it still seems right to me. It should fix not
only the problem Sripathi Kodi saw (can we verify that?), but also a more
fundamental problem with the access of stale memory.

I'll commit it. I would still prefer to have somebody else check out my
logic (or lack there-of).

Linus

On Mon, 8 Nov 2004, Linus Torvalds wrote:
>
> Anyway, if I'm right, the suggested fix would be something like this (this
> replaces the earlier patches, since it also makes the zero return case go
> away - we don't need to mark anything runnable, since we restart the whole
> loop).
>
> NOTE! -EAGAIN should be safe, because the other routines involved can only
> return -EFAULT as an error, so this is all unique to the "try again"
> case.
>
> Ok, three patches for the same piece of code withing minutes. Please tell
> me this one is not also broken..
>
> Linus
>
> ----
> ===== kernel/exit.c 1.166 vs edited =====
> --- 1.166/kernel/exit.c 2004-11-04 11:13:19 -08:00
> +++ edited/kernel/exit.c 2004-11-08 08:34:37 -08:00
> @@ -1201,8 +1201,15 @@
> write_unlock_irq(&tasklist_lock);
> bail_ref:
> put_task_struct(p);
> - read_lock(&tasklist_lock);
> - return 0;
> + /*
> + * We are returning to the wait loop without having successfully
> + * removed the process and having released the lock. We cannot
> + * continue, since the "p" task pointer is potentially stale.
> + *
> + * Return -EAGAIN, and do_wait() will restart the loop from the
> + * beginning. Do _not_ re-acquire the lock.
> + */
> + return -EAGAIN;
> }
>
> /* move to end of parent's list to avoid starvation */
> @@ -1343,6 +1350,8 @@
> (options & WNOWAIT),
> infop,
> stat_addr, ru);
> + if (retval == -EAGAIN)
> + goto repeat;
> if (retval != 0) /* He released the lock. */
> goto end;
> break;
>
-
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/