Add OFD lock support to fcntl and fix l_pid on conflict

[Max042004]

Adds F_OFD_GETLK/F_OFD_SETLK/F_OFD_SETLKW (Linux cmd 36/37/38) to sys_fcntl, which previously fell through to EINVAL. The three cases are guarded by #ifdef F_OFD_GETLK etc. so hosts with older SDKs lacking these constants still build and fall back to EINVAL. Since OFD locks belong to the open file description rather than a process, F_OFD_GETLK now forces the returned l_pid to -1 on a conflict instead of leaking the host PID, matching Linux.

The Linux<->macOS struct flock translation is shared with the existing F_GETLK/F_SETLK/F_SETLKW path via a new fcntl_flock_op() helper rather than duplicated.

Fixes #129

Test plan

• Added tests/test-ofd-lock.c (registered in tests/manifest.txt), covering cross-fd OFD conflict detection, l_pid == -1 on conflict, unlock clearing the conflict, and F_OFD_SETLKW.
• make check green, including the new test and the existing test-flock.
• clang-format --dry-run --Werror clean.

---

Summary by cubic

Adds OFD lock support to sys_fcntl and fixes PID reporting for lock conflicts to match Linux. Restores SQLite WAL and other OFD users; fixes #129.

• New Features

  • Support F_OFD_GETLK/F_OFD_SETLK/F_OFD_SETLKW (guarded by #ifdef).
  • Share Linux↔macOS struct flock translation via fcntl_flock_op().

• Bug Fixes

  • For OFD GETLK, return l_pid = -1 on conflict and reject nonzero request l_pid with EINVAL.
  • For classic F_GETLK, report the conflicting owner as the guest PID via proc_host_to_guest_pid().
  • Tests added: tests/test-ofd-lock.c, updated tests/test-flock.c, and tests/test-matrix.sh updated to run it.

^{Written for commit bb90715. Summary will update on new commits.}

[doanbaotrung]

1. Executed python test script

test_ofd_lock.py file contents:

import fcntl
import os
import struct

# Linux OFD Locking Constants
F_OFD_GETLK = 36
F_OFD_SETLK = 37
F_WRLCK = 1

path = '/tmp/test-ofd-python.db'

# Open two distinct open file descriptions for the same file
fd1 = os.open(path, os.O_RDWR | os.O_CREAT | os.O_TRUNC, 0o644)
fd2 = os.open(path, os.O_RDWR, 0o644)

# Pack a Linux struct flock: hhxxxxqqii (32 bytes)
# l_type = F_WRLCK (1), l_whence = SEEK_SET (0), l_start = 0, l_len = 16, l_pid = 0
lock_data = struct.pack('hhxxxxqqii', F_WRLCK, 0, 0, 16, 0, 0)

print("Taking OFD write lock on fd1...")
fcntl.fcntl(fd1, F_OFD_SETLK, lock_data)

print("Querying conflicting lock on fd2...")
query_data = struct.pack('hhxxxxqqii', F_WRLCK, 0, 0, 16, 0, 0)
res = fcntl.fcntl(fd2, F_OFD_GETLK, query_data)

# Unpack the response
l_type, l_whence, l_start, l_len, l_pid, _ = struct.unpack('hhxxxxqqii', res)

print(f"Conflicting lock type: {l_type} (Expected: 1 for F_WRLCK)")
print(f"Conflicting lock PID: {l_pid} (Expected: -1 for OFD conflict)")

if l_type == F_WRLCK and l_pid == -1:
    print("RESULT: PASS")
else:
    print("RESULT: FAIL")

os.close(fd1)
os.close(fd2)
os.unlink(path)

Command:

elfuse/build/elfuse --sysroot ~/prefixes/ubuntu-arm64/rootfs /usr/bin/python3 test_ofd_lock.py

Output:

Taking OFD write lock on fd1...
Querying conflicting lock on fd2...
Conflicting lock type: 1 (Expected: 1 for F_WRLCK)
Conflicting lock PID: -1 (Expected: -1 for OFD conflict)
RESULT: PASS

2. Executed native host script

clang -Ielfuse/tests third_party/elfuse/tests/test-ofd-lock.c -o /tmp/host_test_ofd
/tmp/host_test_ofd
rm /tmp/host_test_ofd

Output Log:

  F_OFD_SETLK F_WRLCK            OK
  F_OFD_GETLK reports conflict from other OFD OK
  F_OFD_GETLK l_pid is -1 on conflict OK
  F_OFD_SETLK F_UNLCK            OK
  F_OFD_GETLK reports no conflict after unlock OK
  F_OFD_SETLKW F_WRLCK           OK
OK

test-ofd-lock: 7 passed, 0 failed - PASS

[Max042004]

Confirmed — verified against fs/locks.c (fcntl_getlk/fcntl_setlk both reject a nonzero request l_pid with EINVAL for F_OFD_GETLK/SETLK/SETLKW). Fixed in 1180fa2: fcntl_flock_op now reads the guest's l_pid and returns -EINVAL when is_ofd and l_pid != 0, with 3 new regression cases in test-ofd-lock.c.

[doanbaotrung]

Traditional F_GETLK Leaks Host PID to the Guest**

• Location: fcntl_flock_op inside src/syscall/fs.c

• Problem:
  For OFD locks (F_OFD_GETLK), the implementation correctly overrides the conflict PID with -1 (per Linux specification) to avoid leaking host PIDs.

  However, for traditional locks (F_GETLK), it reports:

  rp = mac_fl.l_pid;

  This passes the macOS host process ID directly to the guest. Because elfuse translates and virtualizes guest PIDs, the guest program (e.g., SQLite or other locking monitors) receives a raw host PID (e.g., 40548) instead of the child's guest PID (e.g., 2).

  If the guest tries to manage or check that PID (for example, via kill(conflict_pid, 0)), the PID translation gate in sc_kill looks for the host PID in the guest table, fails to resolve it, and returns ESRCH, even though the process is alive.

• Proposed Fix:
  Add a proc_host_to_guest_pid helper to map the host PID back to its corresponding guest PID via the child process table and cross-process registry.

[Max042004]

Good catch — fixed in da96047. Added proc_host_to_guest_pid() (mirror of the existing proc_guest_to_host_pid()) to translate the conflicting lock's host PID back to a guest PID via the local child table + cross-process registry, so traditional F_GETLK now reports a PID the guest can actually resolve instead of a raw host PID. Also rebased onto main's test-matrix.sh restructuring and added a fork+pipe regression test in test-flock.c that fails without the fix.

[cubic-dev-ai]

1 issue found across 6 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/syscall/proc.c">

<violation number="1" location="src/syscall/proc.c:849">
P2: A first lock-conflict PID lookup in a recycled namespace-owner process can read a stale process registry and return the wrong guest PID. This new registry reader should mirror the existing registry readers by calling `proc_registry_reset_if_owner(path)` before opening the file.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: A first lock-conflict PID lookup in a recycled namespace-owner process can read a stale process registry and return the wrong guest PID. This new registry reader should mirror the existing registry readers by calling proc_registry_reset_if_owner(path) before opening the file.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/syscall/proc.c, line 849:

<comment>A first lock-conflict PID lookup in a recycled namespace-owner process can read a stale process registry and return the wrong guest PID. This new registry reader should mirror the existing registry readers by calling `proc_registry_reset_if_owner(path)` before opening the file.</comment>

<file context>
@@ -805,6 +834,46 @@ int proc_get_namespace_targets(proc_signal_target_t *out,
+    char path[PATH_MAX];
+    if (!process_registry_path(path, sizeof(path)))
+        return -1;
+    int fd = open(path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC);
+    if (fd < 0)
+        return -1;
</file context>

Suggested change

	int fd = open(path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC);
	proc_registry_reset_if_owner(path);
	int fd = open(path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC);

[doanbaotrung]

I think it good now.