lib/9pfs: Stub uk_9pfs_ioctl

[razvand]

Change uk_9pfs_ioctl from vfscore_vop_einval to vfscore_vop_nullop, effectively stubbing it. This means a call to uk_9pfs_ioctl will no longer return -EINVAL, but it will return 0, tricking the caller into thinking ioctl() functionality is available.

This is useful in binary-compatibility mode, where certain ioctl() calls may cause the application to end, if an error code (such as -EINVAL is returned). This is the case of Ruby interpreter running in binary-compatibility mode.

Prerequisite checklist

• Read the contribution guidelines regarding submitting new changes to the project;
• Tested your changes against relevant architectures and platforms;
• Ran the checkpatch.uk on your commit series before opening this PR;
• Updated relevant documentation.

Base target

• Architecture(s): [e.g. x86_64]
• Platform(s): [e.g. kvm]
• Application(s): [e.g. app-elfloader, Ruby in binary-compatibility mode]

[unikraft-bot]

✅ Checkpatch passed

Beep boop! I ran Unikraft's checkpatch.pl support script on your pull request and it all looks good!

SHA	commit	checkpatch
38d7703	lib/9pfs: Stub uk_9pfs_ioctl	✅

[StefanJum]

All good, thanks.
Reviewed-by: Stefan Jumarea stefanjumarea02@gmail.com

[marcrittinghaus]

@razvand This could also create problems if the application depends on the correct behavior of ioctl and we stub the call. I assume for Ruby this is not the case. By any chance, do you remember what ioctl ruby attempts to perform?

[StefanJum]

@razvand This could also create problems if the application depends on the correct behavior of ioctl and we stub the call. I assume for Ruby this is not the case. By any chance, do you remember what ioctl ruby attempts to perform?

@marcrittinghaus it calls fcntl(0x7, F_SETFL, ...), which then calls vfs_ioctl(fp, FIOASYNC...) (which then calls VOP_IOCTL, which is vfscore_vop_einval). So yes, it does try to set O_ASYNC, which we do not support.

[marcrittinghaus]

Ok, does Ruby work at all then? For O_ASYNC we need signals.

[StefanJum]

Ok, does Ruby work at all then? For O_ASYNC we need signals.

Yes, helloworld and other simple stuff works, haven't tried anything else more complex.

[razvand]

@razvand This could also create problems if the application depends on the correct behavior of ioctl and we stub the call. I assume for Ruby this is not the case. By any chance, do you remember what ioctl ruby attempts to perform?

Indeed, the proper solution would be to have a full implementation of ioctl. One way would to stub it only for the command used by Ruby. The issue is actually part of the fcntl() call:

openat(AT_FDCWD, "/usr/lib/ruby/2.5.0/rubygems.rb", O_RDONLY|O_CLOEXEC|O_NONBLOCK) = fd:7
fcntl(0x7, 0x4, ...) = Invalid argument (-22)
close(fd:7) = OK
ioctl(0x2, 0x5401, ...) = 0x0

The value 0x4 is the F_SETFL command for fcntl.

[marcrittinghaus]

openat(AT_FDCWD, "/usr/lib/ruby/2.5.0/rubygems.rb", O_RDONLY|O_CLOEXEC|O_NONBLOCK) = fd:7
fcntl(0x7, 0x4, ...) = Invalid argument (-22)
close(fd:7) = OK
ioctl(0x2, 0x5401, ...) = 0x0

This is interesting. This is another bug in vfscore. The O_NONBLOCK in the openat call should already cause the problem, because it supplies the O_NONBLOCK flag. However, in contrast to fcntl, we don't call vfs_ioctl on the fd when applying the open flags. So depending on the FS this is already broken.

Regarding this PR. For now, it is fine to use vfscore_vop_nullop.

Approved-by: Marc Rittinghaus marc.rittinghaus@unikraft.io