Workspace corruption due to nested acquisition of API Mutex

[strauman]

rtems_task_delete is does most of its work holding the RTEMS allocator mutex. This mutex (_RTEMS_Allocator_Mutex) is created by _API_Mutex_Allocate() in CORE_MUTEX_NESTING_IS_ERROR mode.

Note that _API_Mutex_Lock() does *not* check the return status of the underlying _Core_mutex_Seize()!

I found that the allocator mutex *is* actually acquired recursively at least from one place: during task deletion when the RTEMS API extension is deleted this walks through all task variables and invokes their deletor.

In general it is unknown and therefore not guaranteed that such a deletor might not acquire the allocator mutex -- indeed I found that 'free' which is probably the most common deletor protects the
heap with _RTEMS_Lock_allocator() (i.e., the very allocator mutex)

Because _API_Mutex_Lock() fails to detect the unsuccessful nested attempt the code proceeds and releases the API mutex prematurely (upon return from free(), when the allocator mutex is unlocked).

The resulting lack of protection during the later steps of rtems_task_delete() opens the door for corruption.

[strauman]

Patch that converts the API mutex to a recursive one. It also adds code that checks the return code of operations on the API mutex.

[Sebastian Huber]

The fatal error codes should be unique. Maybe we should add three new ones for RTEMS 4.10.

RTEMS 4.11 and later already allow nesting.

[strauman]

Agreed - however, the proper maintainer should make this decision as well as picking the names...