linux-kernel - Re: COW optimization on exec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090315034134.GA9829@cmpxchg.org>
Date:	Sun, 15 Mar 2009 04:41:34 +0100
From:	Johannes Weiner <hannes@...xchg.org>
To:	sidc7 <siddhartha.chhabra@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: COW optimization on exec

On Sat, Mar 14, 2009 at 07:57:54PM -0700, sidc7 wrote:
> 
> The Linux kernel uses the COW optimization for fork, so the processes share
> the same pages, till on of the processes writes to the page. I was
> wondering, if I do a fork and do an exec immediately following the fork,
> will the COW optimization still be applied as it is most likely that the new
> process is going to write to the shared pages? So doing a COW will not give
> much benefit here, if it is done at all. Can anyone clarify if COW will be
> applied in such a case, for e.g. a command shell.

COWing the pages is not much extrawork, it's handled with this code:

        /*
         * If it's a COW mapping, write protect it both
         * in the parent and the child
         */
        if (is_cow_mapping(vm_flags)) {
                ptep_set_wrprotect(src_mm, addr, src_pte);
                pte = pte_wrprotect(pte);
        }

you can find it in mm/memory.c::copy_one_pte().  The fault handler
will then take care of it (it will notice that the pte is
write-protected while the mapping itself allows writes) and then
replace the page with a copy in the faulting process.

The real overhead is copying the page tables in the first place.  But
the kernel can not know whether exec() is soon to be called, so fork()
always must provide the copy-whole-address-space semantics.

If the forking process knows in advance the child will exec
immediately, it can use vfork() which doesn't copy the address space.

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