Manipulating multiple address spaces

Back in November, LWN covered a patch by Jeff Dike which made some User-mode Linux improvements possible. Jeff needed a mechanism which would allow him to create multiple address spaces for a single Linux process, manipulate those address spaces, and switch the process between them. The interface he came up with was:

• Opening /proc/mm would return a file descriptor representing a newly-created address space.

• Writing to that file descriptor would execute commands on the address space, as described by the data "written." Mapping of segments, changing permissions, etc. would be handled via this mechanism; in this way, UML could set up an address space as needed for one of its processes.

• An extension to the ptrace() system call allows UML to switch a child process's address space.

This interface gets the job done, but it's not too surprising that Linus did not like it. Performing virtual memory management operations via a magic /proc file is just not the most elegant way of doing things.

Cleaning up the first step - creating new address spaces - is relatively easy. It's just a matter of adding a new create_mm() system call. But then how does one manipulate that new space - mapping in a file, or changing protections, for example? The system calls which normally perform these functions (mmap(), mprotect(), ...) are not set up to have a separate address space passed in as a parameter. One could create a whole new set of system calls that take that extra parameter, but that is a task that gets messy in a hurry.

So Linus has come up with another idea. Why not add one more system call (mm_indirect()), which would invoke any other system call in the context of a different address space? mm_indirect() would simply switch the calling process over to the new address space, invoke the real system call of interest, then switch back. In this way, all system calls could be made to manipulate a different address space without the need to modify any of them.

This solution will work for UML, and is thus likely to be implemented. It may eventually lead to a number of currently unimagined "coprocess' applications as well. One question remains unanswered, however: is this sort of change really 2.5 material, or does it get to wait for the next development series?

(As an aside, we look forward to seeing the results of Jeff's work running UML with the valgrind memory debugger. Chances are it will turn up a lot of previously unnoticed memory bugs in the Linux kernel.)

---

(Log in to post comments)