Mike Galbraith wrote:
>
>
> Minus lock_kernel(), that's what I tried (UP box).
> <Andrea>
> I think that's not the correct fix though because there's probably still a
> window for a race if you happen to increase the mmap_sem when it was just
> zero (too late).
> </Andrea>
> Only relevant on SMP?
lock_kernel() closea that race:
noone calls
current->mm=new_value;
mmdrop(old_value);
without lock_kernel.
>
> The troubles I'm seeing begin with a reference to a freed task_struct
> and things go down hill rapidly from there.
>
freed or TASK_ZOMBIE?
TASK_ZOMBIE should be ok, and get_task_struct() should prevent the
kernel from freeing the structure.
Could you add a checkpoints to get_task_struct/free_task_struct: check
if we call get_task_struct for a already freed task.
Btw, which test are you using?
On mu Dual P/ii, I found a bug with
CPU1: execlp(argv[0],argv[0],NULL); in a tight loop
CPU2: $ cd /proc/pid; while true;do cat cmdline > /dev/null;done.
As soon as I start the cat on cpu2, the execlp on cpu1 fails. No oops,
no kernel message, errno=2 (ENOENT).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:16 EST