Re: fork() then clean up

The Linux kernel simply unmaps the pages.

I certainly hope it does more than that!  Wasn't the idea to *free*
them?

No. The idea was to prevent a copy on write. For that, unmapping is
sufficient.

You need to (a) unmap and (b) not leak the block by recording that
it is no longer in use by this process. Now, where in POSIX is
it stated that (a) causes (b) as opposed to (b) causing (a) or
(c) causing both (a) and (b)? This depends a lot on how the kernel
does bookkeeping to keep track of this stuff.

Both (a) and (b) need to get done. If (b) doesn't get done, and the
parent modifies the block, you'll *still* get a copy-on-write with
the original block now belonging to, well, nobody, but since (b)
didn't get done, the kernel doesn't realize it's reclaimable, even
though it should be reclaimable.

Even if it for some reason
can't unmap the pages, no harm is done, an optimization is just lost.

If munmap() unmaps the pages and proceeds to leak the swap space
for those blocks not originally mapped by mmap() by virture of not
freeing those blocks which are not used elsewhere, and not reducing
the use count [1] on ones which are used elsewhere, you have a considerable
pessimization.  You're permanently leaking swap space rather than
holding it used while the parent or the child are running.

If a page is unmapped, it cannot be dirtied or touched.

It could be dirty from pre-fork when the parent touched it.

As a result,
there is no way it could swap either out or in. If a chunk of swap is
not mapped, it is reclaimable.

It *should be* reclaimable, but if the kernel didn't do the bookkeeping
properly, it may not realize it.

.

Relevant Pages
Loading