base-linux ram dataspace file descriptor usage

[Norman Feske]

Hi Johannes,

On 23.03.2018 18:19, Johannes Kliemann wrote:
> I have attached the exact diff that causes the segfault. The kernel
> module that provides the device file and the ioctl is available at [1].
> I have tested it on a Linux system and mapping memory and
> reading/writing it worked flawlessly.

have you tried to add this test directly in '_export_ram_ds' inside
core. That is, 'mmap'ing it locally, writing 'ds->size' number of bytes,
reading them again, followed by clearing them. Just to be sure.

> With this change each component creates a segmentation fault. I was not
> able to trace it, I couldn't even find out in which file it occurs.
> The instruction pointer randomly appeared in
> repos/base/src/lib/base/lock.cc or in repos/base/src/lib/base/heap.cc. I
> have touched neither of these files.

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.

To get a picture where RAM dataspaces are allocated, you may instrument
the client side of the PD session interface, i.e., placing a log message
in base/include/pd_session/client.h inside the 'alloc' method.

> Is there any information about where this is used exactly? I was unable
> to trace the usage of the mapped memory beyond Region_map_mmap::attach.
> I have also traced the calls inside the kernel module and it looks as it
> only uses open, mmap and close so there shouldn't a problem.

I suspect that 'mmap' does not work correctly for some reason (wrong
size calculation, or a permission issue?). Maybe you can print the local
addresses returned by the 'lx_mmap' calls in 'region_map_mmap' and
correlate the fault addresses (as printed by the kernel) with the
instrumentation output? Also, you may try placing the access test (the
one I proposed for core above) here to let the RAM-dataspace-using
component fail predictably instead of randomly, and investigate from there.

Good luck!
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