| Age | Commit message (Collapse) | Author |
|---|
|
The fd-from-air-eventfd-users workload only called timerfd_create then
closed the fd, so timerfd_settime/timerfd_gettime were never exercised
by any integration test. Commit 6ac9fa4 fixed those two syscalls to
KindFd@arg0 (capturing the operating timerfd via fd_event instead of a
null_event), but that fix had no end-to-end coverage.
Extend the workload to arm the still-open timerfd via timerfd_settime
(1s relative expiry, so it never fires) and read it back via
timerfd_gettime before closing. Assert in TestFdFromAirEventfdUsers that
both enter handlers fire (MinCount>=1) and resolve to the "timerfd:"
path prefix, proving arg0 fd is captured rather than null. Locks in the
6ac9fa4 KindFd fix.
splice/tee are NOT touched: retbytes_test.go already asserts
enter_splice/enter_tee plus positive transfer byte counts, which
inherently exercises their arg0 fd capture, so no new coverage is
needed there.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Add an inotify-basic ioworkload scenario and an end-to-end integration
test covering the inotify IPC family, which previously had no integration
coverage (only inotify_init1 had a unit-level eventloop test).
The scenario issues inotify_init1(IN_CLOEXEC) -> inotify_add_watch on a
temp file (IN_CREATE|IN_DELETE|IN_MODIFY) -> inotify_rm_watch -> close.
It is non-blocking: it registers and removes the watch without reading
events, and cleans up the temp dir on return.
TestInotifyBasic asserts enter_inotify_init1, enter_inotify_add_watch,
enter_inotify_rm_watch and enter_close each fire at least once, with
positive durations and PID/comm hermetic guards. The init1 instance fd
resolves to the inotifyfd: path label; add_watch/rm_watch capture the
instance fd@arg0 which resolves to the same registered label.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
mq_timedsend(2)/mq_send(3) return 0 on success or -1 on error; the
payload size msg_len is an INPUT argument, never the return value. It was
wrongly listed in retClassifications as WriteClassified, which made
bytesFromRet attribute its 0 return as "bytes written" (the stats engine
WriteClassified path). Remove it so its return stays UNCLASSIFIED,
consistent with its POSIX mq sibling mq_timedreceive (which legitimately
stays ReadClassified because it returns the received byte count). This is
the exact same defect just fixed for SysV msgsnd (5057bd9) and mirrors
the msgrcv/msgsnd asymmetry.
Regenerated tracepoints/docs accordingly and updated the pre-existing
classify unit test and the TestPosixMqBasic integration assertion: the
mq_timedsend send no longer asserts a write byte count (now expects 0),
while mq_timedreceive keeps its received-byte-count assertion. Verified:
mage generate idempotent, mage build OK, internal/generate tests pass.
TestPosixMqBasic skips in this sandbox (mq_open: permission denied) but
compiles with the corrected assertions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
|
|
|
|
|
|
|
