Hi Johannes,
I implemented this but when I try to attach the dataspace I get a segfault. I though this might be related to a wrong physical address for the file but the backtrace leaves me completely clueless.
#0 pseudo_end () at /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_syscall.S:29 #1 0x000000000109d7c1 in lx_futex (val=0, op=0, uaddr=<optimized out>) at /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/linux_syscalls.h:350 #2 thread_stop_myself () at /media/sf_kernel/genode/repos/base-linux/src/include/base/internal/lock_helper.h:66 #3 Genode::Cancelable_lock::lock (this=this@...551...=0x80ffae0) at /media/sf_kernel/genode/repos/base/src/lib/base/lock.cc:123 #4 0x00000000010b19c8 in Genode::Lock::lock (this=<optimized out>) at /media/sf_kernel/genode/repos/base/include/base/lock.h:33 #5 Genode::sleep_forever () at /media/sf_kernel/genode/repos/base/src/lib/base/sleep.cc:21 #6 0x0000000001065eb8 in Genode::Signal_receiver::block_for_signal (this=this@...551...=0x64b4a70 Genode::bootstrap_component()::startup+3472) at /media/sf_kernel/genode/repos/base/src/core/signal_receiver.cc:49 #7 0x0000000001096a70 in Genode::Entrypoint::_process_incoming_signals (this=this@...551...=0x64b3e40 Genode::bootstrap_component()::startup+352) at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:108 #8 0x000000000109772e in Genode::Entrypoint::Entrypoint (this=0x64b3e40 Genode::bootstrap_component()::startup+352, env=...) at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:329 #9 0x00000000010915ac in Genode::Startup::Startup (this=0x64b3ce0 Genode::bootstrap_component()::startup) at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:244 #10 Genode::bootstrap_component () at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:259 #11 0x00000000010cd016 in _main () at /media/sf_kernel/genode/repos/base/src/lib/startup/_main.cc:248 #12 0x0000000000000000 in ?? ()
are you sure that this is the backtrace of the faulting thread? It doesn't look like it. To double-check, have you had a close look at the instruction pointer within the faulting binary as reported by the kernel's dmesg output?
As another question, did you first try to hand out an FD for a regular file as I suggested in my last email? Just to rule out potential problems with the FD obtained from your kernel module.
The 'rm.attach' - when executed on Linux - is just a process-local operation. It comes down to an invocation of 'mmap' in 'region_map_mmap.cc'. Maybe it helps to instrument the code there? For instrumentation at such a low level, I recommend using the 'raw' function instead of 'log'. The 'raw' function directs the output directly to the kernel - not to core's LOG service. You won't see the component's name as log-message prefix, but rule out any interaction with core by the instrumentation.
Cheers Norman