Hi Norman,
I have tracked down the issue to the Io_mem_dataspace_capability being invalid. The segfault is caused by _dataspace_size() being called on an invalid capability in region_map_mmap.cc. I think a better behaviour would be to check the validity and throw an Invalid_dataspace() exception (I would create a PR for this change).
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?
I have taken a look at the IP and this supports the assumption about the invalid capability as the segfault happens in `Capability_space::ipc_cap_data`, especially in the inlined `return local_capability_space().ipc_cap_data(*cap.data());`
Capability_space::Ipc_cap_data Capability_space::ipc_cap_data(Native_capability const &cap) { 70b40: 53 push %rbx 70b41: 48 8d 05 f8 ff ff ff lea -0x8(%rip),%rax # 70b40 <_ZN6Genode16Capability_space12ipc_cap_dataERKNS_17Nativ e_capabilityE> _ZNK6Genode17Native_capability4dataEv(): /media/sf_kernel/genode/repos/base/include/base/native_capability.h:78 Data const *data() const { return _data; } 70b48: 48 8b 1f mov (%rdi),%rbx 70b4b: 49 bb 50 2f 05 00 00 movabs $0x52f50,%r11 70b52: 00 00 00 _ZN6Genode16Capability_space12ipc_cap_dataERKNS_17Native_capabilityE(): /media/sf_kernel/genode/repos/base/src/lib/base/capability_space.cc:81 return local_capability_space().ipc_cap_data(*cap.data()); 70b55: 48 ba 40 cb fa ff ff movabs $0xfffffffffffacb40,%rdx 70b5c: ff ff ff 70b5f: 4c 01 d8 add %r11,%rax 70b62: 48 01 d0 add %rdx,%rax 70b65: ff d0 callq *%rax 70b67: 48 8b 53 08 mov 0x8(%rbx),%rdx 70b6b: 8b 43 10 mov 0x10(%rbx),%eax /media/sf_kernel/genode/repos/base/src/lib/base/capability_space.cc:82 } 70b6e: 5b pop %rbx 70b6f: c3 retq
70b67 is the instruction that fails. I don't know if this helps you in any way.
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.
This happens no matter which file I have opened.
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.
I looked into other implementations of base-linux that use the Dataspace_capability. They all just instanciate and return it. This is also the case for the Io_mem_dataspace_capability yet it seems to be invalid by default. I tried to return a Dataspace_capability but it can't be casted. As far as I understand it I have to either validate the Io_mem_dataspace_capability or cast to it.
Regards, Johannes