This patch eliminates the "no attachment at..." warnings, which
were caused by a use-after-free problem of dataspaces. When a
dataspace was destroyed, the users of the dataspace were not
informed and therefore could not revert possible attachments to
RM sessions. The fix introduces a callback mechanism that allows
dataspace users (i.e., RM regions) to register for the event that
a dataspace vanishes.
The following types of dataspaces are handled:
* RAM dataspaces
* ROM dataspaces
* The process binary
* The binary of the dynamic linker
* Args dataspace
* Sysio dataspace
* Env dataspace
* managed RM dataspaces
The handling of ROM dataspaces is still not complete. When forking,
the ROM dataspace of the parent process gets just reused without
creating proper meta data ('Dataspace_info') for the forked process.
Similar issues might arise from other special dataspaces (e.g.,
args, env, sysio).
This patch removes all "no attachment at..." warnings except for
one (an attachment at 0).
Issue #485
This patch extends the RAM session interface with the ability to
allocate DMA buffers. The client specifies the type of RAM dataspace to
allocate via the new 'cached' argument of the 'Ram_session::alloc()'
function. By default, 'cached' is true, which correponds to the common
case and the original behavior. When setting 'cached' to 'false', core
takes the precautions needed to register the memory as uncached in the
page table of each process that has the dataspace attached.
Currently, the support for allocating DMA buffers is implemented for
Fiasco.OC only. On x86 platforms, it is generally not needed. But on
platforms with more relaxed cache coherence (such as ARM), user-level
device drivers should always use uncacheable memory for DMA transactions.
Norman Feske