Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Philippe Gerum wrote:
> On Sat, 2010-08-21 at 19:36 +0200, Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> There are other issues to consider, such as detecting that a private
>>> mutex created in the father continues to be used in the child.
>> A simple fix for this would be to keep a list of mutexes in the native
>> and posix skin, and nullify their magic/opaque pointer at fork. The
>> problem is that there is no more room in pthread_mutex_t, so we will
>> have to malloc at pthread_mutex_init time.
>>
> 
> Please simply issue a warning as you suggested once when a potentially
> dangerous situation arises upon fork regarding mutexes. Piling up
> non-trivial code to prevent an obviously broken application from
> misbehaving even more is way too expensive if such code could introduce
> more overhead, and potentially secondary mode switches.
> 
> IIUC, we are discussing about apps using in a child context some private
> mutexes which were initially created in the parent context, right? If
> so, then a warning upon detection should suffice to have the author go
> back to the drawing board, and optionally run "man pthread_mutex_init"
> as well.

Ok. Detection is not that easy with fastsyncs, so here what I set up to do:
- for mutexes going through the syscall path, return EPERM (the
documented error for that case), and print a message inn the console.
- for mutexes going through fastsync, cause a segmentation fault to kill
the application by setting up an inaccessible mapping where the private
heap was, this is better than potential silent memory corruption (the
current situation). But needs be documented.

-- 
					    Gilles.