Re: mapping pages into new address spaces

[Joshua Haberman]
> I do, however, want to make one final suggestion, which is a much
> more minor change than either of my previous two.  The suggestion
> is: make maps/grants from a pager to any of its threads *always*
> ignore the target thread's acceptor.

> There should be no security implications: a thread has no illusion
> of being able to protect its address space from its pager, since a
> pager gets to ignore the acceptor every time a page fault happens.

A client might want to request memory from its pager which is mapped
into a particular location of its address space.  Your proposal
prevents such operation.

> This shouldn't muddy up the API spec or reference manual: instead of
> writing in the page fault protocol that maps/grants will ignore the
> target thread's acceptor, write this in the section about
> maps/grants that they will *always* ignore the target thread's
> acceptor.  This actually makes things more consistent, because it
> makes page fault IPC more like other IPC.

How so?  Because page faults IPCs now ignore the acceptor and regular
IPCs don't?  I don't get it.

> It shouldn't complicate the implementation, because instead of
> saving/restoring MR0 when a page fault happens, you can make the
> map/grant IPC path simply skip the acceptor logic if the sender is
> the pager for the receiver.  It's arguably a simpler implementation.

Actually no.  You introduce special cases for mappings from the pager.

> And finally, I can't think of a case where threads will want the
> feature of having pages from their pager be subject to an acceptor
> -- the pager needs to know everything about the thread's address
> space in order to properly respond to page faults in it, so the
> pager should have enough information to never erroneously map to an
> area that is already mapped.

> What I keep coming back to is that I think maps from a thread's
> pager are fundamentally different than maps from anyone else.  A
> normal thread will have its acceptor always set to an area of its
> memory that it doesn't mind having mapped by anonymous strangers.
> But a thread's pager is not an anonymous stranger -- it is the
> thread that is in control of managing the thread's address space.
> To do this job properly, it seems that it should have the ability to
> map anywhere into its threads address spaces without making their
> threads set/reset their acceptors all the time.

A pager does not necessarily have to always take on the role of a
pager.  Your proposal assumes that this is so.  You're also not taking
into account race conditions that could happed if the pager of the
client is modified at runtime.  This could for example happen when a
thread is migrated to another CPU, and in order to avoid cross
processor IPCs you also change the pager of the thread in the process.

> In fact, there seems to be risk in asking clients to set/reset
> acceptors.  Let's say that a pager wants to provide an API like
> mlock() to its clients -- that is, ensure that a region of the
> address space is in RAM and will not page fault.  Because of the
> acceptor scheme, clients will have to set their acceptor to the
> entire address space before they make this call (or at least to the
> portion they are trying to mlock()), and reset it once the call
> returns.  But suppose that the pager is busy when the thred makes
> this IPC, and is not waiting on a receive.  Another thread is
> scheduled in, and it sends a map/grant to the thread that overwrites
> a mapping it already had.  The thread had no way of making sure that
> *only* its pager could take advantage of its weaker acceptor.

Yes it does.  All IPCs (including mappings) are synchronous.  This
means that a thread can not receive mappings into its address space
unless it explicitly performs a receiving IPC.  I think you might not
be realizing that a pagefault raised by a thread will temporarily set
the acceptor of the faulting thread to the complete address space for
the duration of the RPC (and set it back to the original value
afterwards), no matter what the original value of the acceptor was.

	eSk