Shim sendfile to EINVAL

[datacompboy]

Describe the issue Java's transferTo tries to use sendfile and fallback to read/send in case of EINVAL

To Reproduce Try to run Kafka under Shadow

Shadow (please complete the following information):

• Version and build information:

  Shadow 3.1.0 — v3.1.0-225-g04565a6f7-dirty 2024-06-03--11:33:51
  GLib 2.72.4
  Built on 2024-06-21--11:42:16
  Built from git branch main
  Shadow was built with PROFILE=debug, OPT_LEVEL=1, DEBUG=true, RUSTFLAGS="-C force-frame-pointers=y", CFLAGS="-std=gnu11 -O0 -ggdb -fno-omit-frame-pointer -Wreturn-type -Wswitch -DDEBUG"

• Which processes you are trying to run inside the Shadow simulation: Kafka

Additional context Just adding EINVAL shim to src/main/host/syscall/handler/mod.rs:

+            SyscallNum::NR_sendfile => {
+                log::trace!("Return EINVAL for sendfile {} ({})", syscall_name, ctx.args.number);
+
+                let rv = Err(Errno::EINVAL.into());
+
+                log_syscall_simple(
+                    ctx.objs.process,
+                    ctx.objs.process.strace_logging_options(),
+                    ctx.objs.thread.id(),
+                    syscall_name,
+                    "...",
+                    &rv,
+                )
+                .unwrap();
+
+                rv
+            }

Makes java fallback to read+recv.

[sporksmith]

Also touched on in this issue about some other IO syscalls used by Java golang: https://github.com/shadow/shadow/issues/3322

Also this broader issue about policies/features around these sort of "stub" implementations: https://github.com/shadow/shadow/issues/3280

Offhand, I think this particular syscall would be fairly easy to implement for real.

[sporksmith]

Offhand, I think this particular syscall would be fairly easy to implement for real.

Ah, actually #3322 talks about this; we probably need a little bit of refactoring to handle these sort of syscalls.