Processes and mmap

[Georgi Chulkov]

> > 1) Why is the shared address space "back" necessary?
>
> For handling things like the zlib compression state.  This state
> includes things like compression dictionaries that are needed to
> decompress the data from the client, and their content changes over time.
>
> Since zlib compression can be negotiated before the connection is
> authenticated, it means that the compression state has to be available
> to both the preauth and post-auth privsep slaves.

I understand that there are things that need to remain between the slaves. I 
do not understand why mm is not sufficient by itself. 

> > 2) What does mm_share_sync do?
>
> The shared memory allocator keeps accounting records of its allocations.
>   For the most part these are held in normal dynamically allocated memory.
>
> When the first privsep process exits, it copies these accounting records
> to the shared memory area in a format that the new (post-auth) privsep
> process can unpack and use to continue managing the shared memory area.

I'm sorry, I still don't get it. So shared memory is kept in mm. mm itself was 
created by the monitor process, so nothing in there goes away when the first 
privsep slave exits. Why can't the monitor just pass mm back to the second 
slave?

Also, if mm_share_sync copies shared memory allocator metadata, where does it 
copy it to?

> > 3) What is the difference between mm using libc's malloc, as opposed to
> > mm using back which itself uses libc's malloc?
>
> I'm not sure I follow this question.  If you allocate memory from "back"
> the memory you allocated is in the shared memory area.  The information
> about the allocation (the metadata) is in non-shared memory, and this
> metadata is what is copied by mm_share_sync.

This question directly addresses the paragraph I pointed to in my last e-mail. 
You say "If you allocate memory from 'back' the memory you allocated is in 
the shared memory area." Is this not true of 'mm' too?

To paraphrase my question, why do we use mm_share_sync to save back's metadata 
(which holds mm's metadata), as opposed to using mm_share_sync to save mm's 
metadata directly and not having back at all?

Thanks again.

Georgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080704/6b559202/attachment.bin