Using open() or openat() to create a file under binary-compatibility mode (i.e. using the O_CREAT flag) fails when using 9PFS. This is caused by PR unikraft/unikraft#914, that changes the 9P version from 2000.U to 2000.L.
This doesn't happen under native mode, by invoking the open() call (see details below).
open("a.txt", O_RDONLY|O_CREAT|0x2) = Operation not permitted (-1)
Note that using open.c in a native Unikraft build works. You have to enable 9PFS + VFSCore support in the native build to make it run; Musl is not required.
Expected behavior
The open() or openat() system calls should succeed. They would return a file descriptor:
open("a.txt", O_RDONLY|O_CREAT|0x2) = fd:3
Which architectures were you using or does this bug affect?
x86_64
Which platforms were you using or does this bug affect?
Describe the bug
Using
open()
oropenat()
to create a file under binary-compatibility mode (i.e. using theO_CREAT
flag) fails when using 9PFS. This is caused by PR unikraft/unikraft#914, that changes the 9P version from2000.U
to2000.L
.This doesn't happen under native mode, by invoking the
open()
call (see details below).My investigation led me to locating the issue at line
216
inlib/uk9p/9preq.c
in theuk_9preq_error()
function. The call trace is:The
req->recv.type
is7
(UK_9P_LRERROR
) causing the comparison in line216
to fail.Steps to reproduce
open-static-pie.zip consists of the source code files and prebuilt PIE binaries that can be used with
run-app-elfloader
. Use therun.sh
script:You would then capture an error message:
Note that using
open.c
in a native Unikraft build works. You have to enable 9PFS + VFSCore support in the native build to make it run; Musl is not required.Expected behavior
The
open()
oropenat()
system calls should succeed. They would return a file descriptor:Which architectures were you using or does this bug affect?
x86_64
Which platforms were you using or does this bug affect?
kvm
Relevant log output