Re: [PATCH] tmpfs: now working

[Roland McGrath]

> I don't have the previous messages, but I did grasp this much from the
> code.  It might be that this is ultimately just a short-term hack for
> a tmpfs, however, and we have to hobble together what kludges work
> with it.  I have some ideas about what the Right Thing would be; they
> all require interaction between the default pager and the tmpfs
> server.

If you are referring just to the question of tracking user send rights to
the memory object (i.e. io_map was called), then I can think of only one
approach that avoids interaction with the default pager.  That is simply
never to drop the node, e.g. add a weak ref on the first io_map call and
have the dropweak function release it iff st_nlink==0.  Then tmpfs files
that have been mmap'd always have "in-core" diskfs state until they're
removed.  Sleazy, but basically harmless.

> It is perfectly kosher to go ahead and add such interfaces, as long as
> you don't hose the privileged threads of the default pager with them.

I'm not worried about kosher.  I'm worried about breaking the thing and
being too much of a lame ass to want to debug it.

> Faults are, well, ok.  We'll never be able to give them on a
> default-pager based interface, of course.

What I'd had in mind was new default_pager_object calls to fix the size of
a memory object (and clear pages past the new end).  Those changes are
pretty simple, and make faults work right.

> Can you cite the Posix that you think is relevant?

But the book is two whole armlengths away, and it's ... so ... heavy.
Oh, alright.  I went and looked.  It's got a "shall" in the line;
I think I was right.  1003.1-1996 12.2.1 (mmap) p 274 ll 288-290:

 [...] references [...] to whole pages following the end of an object shall
 result in the generation of a SIGBUS signal.

In the context "object" means "file or shared memory object" (shm_open).
So I think "end of object" really does mean st_size of a file, and this
really is a binding requirement of the standard.