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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
