Re: [PATCH] proxy memory object

[Marcus Brinkmann]

At Sun, 12 Jun 2005 19:07:52 -0700 (PDT),
Roland McGrath wrote:
> 
> > There is something funky about the arrays.  I originally wanted to use
> > "^array[]", but that was a loser.
> 
> What was the problem?

I didn't see the right data.

> I haven't played with ^array[], but I know about
> out-of-line parameters generally in the kernel.  The server stub gets
> passed a vm_map_copy_t (cast to io_buf_ptr_t, i.e. char *) when the
> parameter is out of line.You have to use vm_map_copyout on kernel_map to
> look at the contents.

Ah, ok.  That must have been it, I just tried to use the pointer
directly.  Do you think it is worth to go through this trouble here?

> > The patch is tested and seems to work just fine for a single memory
> > object, where offset and start are 0 and len is ~0.
> 
> store_map (or store type map hooks) could use this to fabricate a memory
> object for a partitoin or remap store.  That would test some useful cases
> with offsets and limits.  I really think at least some elementary tests of
> the nontrivial arguments should be tested before it goes in.
> 
> Hmm, it looks like you haven't implemented that stuff at all, not just not
> tested it.

Right.

> I am a little dubious about putting in the RPC with all those
> args when they aren't implemented.  I suppose there won't be many users to
> change if the signature winds up changing.

Yeah, all-right, but I would be happy if you could make up your mind
on this.  Last time this came up I posted a complete, working patch
with just the args I needed for the simple case.  At that time, Thomas
asked me to modify the prototype to allow for a range restriction, and
you asked me to also take into account multiple objects.

There are three options here, and I don't really care which one we go for:

1. Apply my original patch from Nov 20 2002 (!!!).
   But why didn't we do it 2-and-a-half years ago when I already made
   clear that I won't implement the generic case fully?
2. Apply my new patch, with the generic interface.
3. Somebody commits _now_ to implement the generic case within a reasonably
   short time frame.  I won't do it.

This is, for me, all about fixing a glaring security hole, which has
existed ever since.  Well, since some time it is also about allowing
for tmpfs and shared memory, but that is a side-issue.

Thanks,
Marcus