Re: [PATCH] tmpfs: now working

[Thomas Bushnell, BSG]

Neal H Walfield <neal@cs.uml.edu> writes:

> > Diskfs_drop_node is called only when there are no outstanding
> > references to the file: including memory objects.  If there is a
> > memory object reference of any kind, and diskfs_drop_node is being
> > called, you have a serious bug.  
> 
> This is wrong.  Consider mmap;  By SUSv2, we are allowed to:
> 
>       fd = open (foo, ...);
>       data = mmap (fd, ...);
>       close (fd);
> 
>       *data = ...;
> 
> As we implement mmap by passing a reference to a memory object port to
> the user, we never know when all of the references are gone.

You are quite right about what user code should work.

When the user does mmap, the C library briefly acquires a reference to
the memory object, and then vm_map moves that reference into the
kernel, which holds on to it for as long as the region remains
mapped.  This is a normal send right.

Once the mapping goes away, the kernel releases the send right, and a
no-senders notification is sent, and the server has the opportunity to
DTRT.

Now you've chosen a hack: handing out memory objects from some other
source, ones that you don't actually have enough control over to
implement the protocol correctly.  There are many ways to fix it (one
would be to improve the interaction between tmpfs and default_pager).  

But you aren't keeping track of ths reference at all: you are entirely
ignoring it, and then (go figure) diskfs_drop_node gets called when
there is still a reference.  That might be OK, like I said, but it
isn't the model, and you have to be aware of the problem.

> > I would just bzero the region by hand if necessary,
> 
> True, however, consider that we do not know what the real size of the
> memory object is.  We only know what the user have told us.  A user can
> always fake us out by mapping in more than he said he was going to.

Ah, that's a good reason that you can't zero the memory in
diskfs_truncate.  That means you can't deal with a possible
information leak security hole, but I'm not sure there's a real hole
there anyway.

But for the mere correctness concern, you must guarantee that when the
file is extended from size N to size M, the gap is zeroed.  You don't
promise anything about what's out past M, so if you choose the "zero
memory in diskfs_grow" method, you are required to zero the amount
between the old size and the new size, and that's all.