base-linux ram dataspace file descriptor usage

[Norman Feske]

Hello Jonhannes,

>> RAM dataspaces are used as backing store for any dynamically allocated
>> memory. So it is not surprising to see this fault in the heap. The
>> segmentation fault in the lock implementation is certainly caused by a
>> lock that resides within a dynamically allocated object.
> 
> Could this have to do with using a vfork like mechanism instead of fork?
> So that the Capability is passed but the mapping doesn't exist any more
> for the child?
> I could verify that the segmentation fault only appears after clone in
> the child.

the problem could very well be related to the process-creation
mechanism. All processes are created by forking from core (via clone).
Look out for 'lx_create_process'. Dataspaces are normally attached via
the 'MAP_SHARED' flag passed to 'mmap'. May it be that the mmap handling
of your kernel module somehow misses to consider this flag? (not that I
would know how to handle it)

> Both ranges seem to reside in 0x7fffe7ffe000 which is the return value
> of the first lx_mmap after clone (unfortunately I cannot tell if this
> happens in the parent or in the child).

To get a clearer picture, an instrumentation as illustrated in the
attached patch can be helpful. The 'wait_for_continue' function waits
until the user presses return. By placing it in the process-creation
code path, you can probe the state at various points. By printing the
return value of 'lx_gettid()' in your messages, you can see who is
talking. The 'wait_for_continue' hook also provides you with a
convenient way to attach GDB *before* the interesting code parts are
executed. By using the 'Genode::raw' function instead of 'Genode::log'
for log output, messages go directly to the kernel, not to core's LOG
service. So you can instrument lowest-level details (like IPC and
process creation) without fearing any deadlocks.

In order to let the key presses reach Genode, you need to change the run
script to use 'run_genode_until forever', which puts the expect tool in
interactive mode. The attached patch changes the 'run/log.run' script as
an example.

The instrumentations with 'wait_for_continue' also allow you to inspect
'/proc/<PID>/maps' of core and init at various stages of the process
creation. Thereby you can derive the information about the backing store
for virtual-address areas. E.g., assuming that a mapping is missing in
init (the forked process) right after clone - eventually producing a
segmentation fault, you can look into the 'maps' file of core to see the
origin (file) of the original mapping at the fault address.

I hope that these debugging hints are of help for your further
investigation.

Cheers
Norman


-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug_lx_create.patch
Type: text/x-patch
Size: 1180 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20180329/c7fbc333/attachment.bin>