Re: [patch] Fixed the race that was oopsing Linux-2.2.0
Richard Gooch (rgooch@atnf.csiro.au)
Wed, 27 Jan 1999 15:59:55 +1100
Andrea Arcangeli writes:
> As first the memcpy in dst (removed from pre9 to 2.2.0 final) is needed
> because while get_stat and get_stats are running the process could gone
> away. If we don't want to memcpy we need the tasklist_lock locked (but
> the memcpy looks more obviously right to me, at least at this clock
> time...).
>
> The other problem that was harming all people is that mmget() was
> incrasing the counter unconditionally. But it could increase it even if it
> was just 0. So we could have an mm with count 1 (increased by /proc), but
> just dealloced by do_exit() because do_exit run between the check for mm
> != &init_mm and mmget() (in get_mm_and_lock() if I remeber well).
>
> Here the complete fix against 2.2.0 (the fix will be in 2.2.0_arca-3
> soon):
>
> Index: arch/i386/kernel/ldt.c
> ===================================================================
> RCS file: /var/cvs/linux/arch/i386/kernel/ldt.c,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 ldt.c
> --- ldt.c 1999/01/18 01:28:57 1.1.1.1
> +++ linux/arch/i386/kernel/ldt.c 1999/01/27 02:38:45
> @@ -83,7 +83,7 @@
> set_ldt_desc(i, ldt, LDT_ENTRIES);
> current->tss.ldt = _LDT(i);
> load_ldt(i);
> - if (atomic_read(&mm->count) > 1)
> + if (mm->count > 1)
> printk(KERN_WARNING
> "LDT allocated for cloned task!\n");
> } else {
The parts of your patch like this are completely bogus! If this fixes
anything for you, it just means you are lucky and are avoiding some
kind of race condition.
What is the theory about removing the atomic_read() calls?
Regards,
Richard....
-
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/