With this patch, the 'Signal_receiver::dissolve()' function does not return
as long as the signal context to be dissolved is still referenced by one
or more 'Signal' objects. This is supposed to delay the destruction of the
signal context while it is still in use.
Fixes#594.
Remove signal context object from signal source component list (_signal_queue)
before destruction, otherwise we get a dangling pointer.
On native hardware for base-nova, the signal source thread triggered page
faults in the Signal_source_component::wait_for_signal() method when the signal
context got freed up in Signal_session_component::free_context but was still
enqueued in Signal_source_component::_signal_queue.
Fixes#600
Several users of the signal API used custom convenience classes to
invoke signal-handling functions on the reception of incoming signals.
The 'Signal_dispatcher' pattern turned out to be particularly useful. To
avoid the duplication of this code across the code base, this patch
adds the interface to 'base/signal.h'.
Furthermore, the patch changes the 'Signal::num()' return type from int
to unsigned because negative numbers are meaningless here.
Fixes#511
Add functionality to lookup an object and lock it. Additional the case is
handled that a object may be already in-destruction and the lookup will deny
returning the object.
The object_pool generalize the lookup and lock functionality of the rpc_server
and serve as base for following up patches to fix dangling pointer issues.
When releasing a lock we must take care that all state is written back to
memory and is not cached in registers. The volatile flag of the lock variable
only means to the compiler that this value must be written immediately.
Other values changed before may be kept by the compiler in registers, which we
don't want here.
Additionally the compiler is free to reorder the code in order to optimize.
That means the code we intend to be executed inside the critical section can
get be reordered and can be executed after we reset the lock variable in the
unlock implementation. The volatile statement of the lock variable doesn't
prevent reordering of instructions which are independent.
By adding a explicit memory barrier, we force the compiler to generate code
that writes back all the register content to memory/cache (and avoid a
bunch of hard to find bugs ...)
The CPU session interfaces comes with the ability to install an
exception handler per thread. This patch enhances the feature with the
provision of a default signal handler that is used if no thread-specific
handler is installed. The default signal handler can be set by
specifying an invalid thread capability and a valid signal context
capability.
Furthermore, this patch relaxes the requirement of the order of the
calls of 'exception_handler' and 'set_pager'. Originally, the exception
handler could be installed not before setting a pager. Now, we remember
the installed exception handler in the 'Cpu_thread' and propagate to to
the platform thread at a later time.
It happens that ram_session and rm_session itself are invoking alloc
respectively free on the very same sliced heap inside core.
Lock only the sliced_heap list implementation and let the session locking to
the session implementation of rm_session and ram_session.
The ram_session and rm_session must take care to proper lock since inside
both implementations already the session handling thread and the service thread
are running parallel.
With commit 1389b63050 in thread.cc for base-foc
a bug was fixed, where the memory of the context got freed up before running
the de-constructor.
Apply the fix also to base and base-mb.
For base-nova thread creation related exception can be thrown, since the
Pager_objects are threads. Catch the exception and re-throw the
expected/documented exception in rm_session.
This commit avoids that core dies with an unhandled exception if a thread
couldn't be created (e.g. because the limit has been reached).
Sanity check that the context area has been attached. Otherwise the code
later tries to access the context area and core dies with a unhandled page
fault.
The Linux version of core used a part of the BSS to simulate access to
physical memory. All dataspaces would refer to a portion of 'some_mem'.
So every time when core would access the dataspace content, it would
access its local BSS. For all processes outside of core, dataspaces were
represented as files. This patch removes the distinction between core
and non-core processes. Now, core uses the same 'Rm_session_mmap'
implementation as regular processes. This way, the 'some_mem' could be
abandoned. We still use BSS variable for allocating core-local meta
data through.
This patch reflects eventual allocation errors in a more specific way to
the caller of 'alloc_aligned', in particular out-of-metadata and
out-of-memory are considered as different conditions.
Related to issue #526.
This patch introduces clean synchronization between the entrypoint
thread and the caller of the 'Rpc_entrypoint' destructor. The most
important change is the handling of the 'Ipc_server' destruction. This
object is in the local scope of the server's entry function. However,
since the server loop used to be an infinite loop, there was hardly any
chance to destruct the object in a clean way. Hence, the
'Rpc_entrypoint' destructor used to explicitly call '~Ipc_server'.
Unfortunately, this approach led to problems because there are indeed
rare cases where the server thread leaves the scope of the entry
function, namely uncaught exceptions. In such a case, the destructor
would have been called twice.
With the new protocol, we make sure to leave the scope of the entry
function and thereby destroy the 'Ipc_server' object as expected. This
is achieved by propagating the exit condition through a local RPC call
to the entrypoint. This way, the blocking state of the entrypoint
becomes unblocked. Furthermore, '~Rpc_entrypoint' makes use of the new
'join' function to wait for the completion of the server thread.
There is no obvious reason for having two different SPEC variables, definitions,
and pathes for the Pandaboard platform. It even lead to problems regarding the
omap4 framebuffer driver (look at issue #505 and #506).
On Linux, we want to attach additional attributes to processes, i.e.,
the chroot location, the designated UID, and GID. Instead of polluting
the generic code with such Linux-specific platform details, I introduced
the new 'Native_pd_args' type, which can be customized for each
platform. The platform-dependent policy of init is factored out in the
new 'pd_args' library.
The new 'base-linux/run/lx_pd_args.run' script can be used to validate
the propagation of those attributes into core.
Note that this patch does not add the interpretation of the new UID and
PID attributes by core. This will be subject of a follow-up patch.
Related to #510.
Using the new 'join()' function, the caller can explicitly block for the
completion of the thread's 'entry()' function. The test case for this
feature can be found at 'os/src/test/thread_join'. For hybrid
Linux/Genode programs, the 'Thread_base::join()' does not map directly
to 'pthread_join'. The latter function gets already called by the
destructor of 'Thread_base'. According to the documentation, subsequent
calls of 'pthread_join' for one thread may result in undefined behaviour.
So we use a 'Genode::Lock' on this platform, which is in line with the
other platforms.
Related to #194, #501
The IPC-server object exists solely on the stack of the entrypoint
thread and, therefore, would never be destructed as the thread is just
killed. Now, the object is explicitly destructed in the entrypoint
destructor. An alternative solution could instruct the entrypoint thread
the terminate, which would automatically cleanup its stack.
The object pool is assumed to be empty on destruction of the entrypoint.
If not, we warn and at least dissolve all RPC objects.
You cannot check an unsigned size_t variable for underflow, so I
changed the code to first check if an underflow would occur before
performing the subtraction.
Fixes#489.
'Core_tlb' ensures that core never throws pagefaults,
in contrast to its base 'Tlb' that is planned to use displacement
in the future.
'Core_tlb' enables the application of differenet memory attributes
in core, according to the board specific partitioning of the physical
address space. This way it enables caching in core.