Re: [BUG][PATCH] 2.4.* mlockall(MCL_FUTURE) is broken -- child inherits

Andrew Morton (akpm@zip.com.au)
Tue, 08 Jan 2002 13:55:43 -0800


Dave Anderson wrote:
>
> In 2.4.*, mlockall(MCL_FUTURE) is erroneously inherited by child processes
> across fork() and exec():

The Linux manpage says that it is not inherited across either.

However SUS says that it is not inherited across exec, and
doesn't mention fork() at all.
http://www.opengroup.org/onlinepubs/007908799/xsh/mlockall.html

So... Shouldn't we be clearing it in the exec() path?

> ...
> # diff -u linux/kernel/fork.c linux-2.4.17/kernel/fork.c
> --- linux/kernel/fork.c Tue Jan 8 15:11:13 2002
> +++ linux-2.4.17/kernel/fork.c Tue Jan 8 15:12:26 2002
> @@ -219,6 +219,7 @@
> init_rwsem(&mm->mmap_sem);
> mm->page_table_lock = SPIN_LOCK_UNLOCKED;
> mm->pgd = pgd_alloc(mm);
> + mm->def_flags = 0;
> if (mm->pgd)
> return mm;
> free_mm(mm);
>
> Note that it worked OK in 2.2 because mm->def_flags was explicitly cleared in
> mm_alloc(), which was called by both copy_mm() and exec_mmap(). But things
> were shuffled around a bit in 2.4, and it must have gotten lost in the
> translation...

um. Is this correct? It seems that we'll be clearing things
like VM_IO on device mappings across fork. Bad. Would an explicit
clear of VM_LOCKED be better here? (Assuming we want to ignore SUS).

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