Hi all,

I'm struggling with modifying the Ram_dataspace in base-linux.
I have replaced the file descriptor opened in
> void Ram_dataspace_factory::_export_ram_ds(Dataspace_component *ds)
in base-linux/src/core/ram_daraspace_support.cc by opening a special
device file that provides mappable ram.

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.

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.

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'd like to give you further information about this but I have
absolutely no idea by myself.

Regards,
Johannes

[1]:
https://github.com/jklmnn/hwiodev/blob/0f5d367162812ee015434e5b97fdf208ef362215/hwio.c
diff --git a/repos/base-linux/src/core/include/core_linux_syscalls.h b/repos/base-linux/src/core/include/core_linux_syscalls.h
index fb176e0db..42a7bfd37 100644
--- a/repos/base-linux/src/core/include/core_linux_syscalls.h
+++ b/repos/base-linux/src/core/include/core_linux_syscalls.h
@@ -106,6 +106,11 @@ inline int lx_ioctl_irq(int fd, int irq)
     return lx_syscall(SYS_ioctl, fd, _IOW('g', 2, int*), &irq);
 }
 
+inline int lx_ioctl_dma(int fd, Genode::size_t size)
+{
+    return lx_syscall(SYS_ioctl, fd, _IOW('g', 3, Genode::size_t*), &size);
+}
+
 /**************************************
  ** Process creation and destruction **
  **************************************/
diff --git a/repos/base-linux/src/core/ram_dataspace_support.cc b/repos/base-linux/src/core/ram_dataspace_support.cc
index 116210643..006ec3b44 100644
--- a/repos/base-linux/src/core/ram_dataspace_support.cc
+++ b/repos/base-linux/src/core/ram_dataspace_support.cc
@@ -38,10 +38,9 @@ void Ram_dataspace_factory::_export_ram_ds(Dataspace_component *ds)
 	char fname[Linux_dataspace::FNAME_LEN];
 
 	/* create file using a unique file name in the resource path */
-	snprintf(fname, sizeof(fname), "%s/ds-%d", resource_path(), ram_ds_cnt++);
-	lx_unlink(fname);
-	int const fd = lx_open(fname, O_CREAT|O_RDWR|O_TRUNC|LX_O_CLOEXEC, S_IRWXU);
-	lx_ftruncate(fd, ds->size());
+
+        int const fd = lx_open("/dev/hwio", O_RDWR|O_SYNC|LX_O_CLOEXEC);
+        lx_ioctl_dma(fd, ds->size());
 
 	/* remember file descriptor in dataspace component object */
 	ds->fd(fd);
@@ -52,7 +51,6 @@ void Ram_dataspace_factory::_export_ram_ds(Dataspace_component *ds)
 	 * gone (i.e., an open file descriptor referring to the file). A process
 	 * w/o the right file descriptor won't be able to open and access the file.
 	 */
-	lx_unlink(fname);
 }
 
 
------------------------------------------------------------------------------
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

Reply via email to