| Age | Commit message (Collapse) | Author |
|---|
|
Audit of bind(2): int bind(int sockfd, const struct sockaddr *addr,
socklen_t addrlen). Verified the existing classification is correct and
consistent with its socket-setup siblings connect/listen/accept/
getsockname/getpeername:
- KindFd, capturing ev->fd = args[0] (the sockfd); the addr pointer and
addrlen are not captured.
- FamilyNetwork.
- Exit is UNCLASSIFIED (returns 0/-1, no transferred byte count).
No implementation or doc changes were needed (docs/syscall-tracing-plan.md
already lists bind under Network and fd; drift test green). Added
regression coverage:
- FormatBind/FormatExitBind fixtures mirroring the real kernel tracepoint.
- TestGenerateBindHandler with negative guards (no probe_read on the
sockaddr, no fd capture from args[1]/args[2], exit stays UNCLASSIFIED).
- bind + connect/listen/getsockname/getpeername added to the
family (FamilyNetwork) and ret-classification (UNCLASSIFIED) lock-in
lists.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audit of signalfd4(2) confirmed the tracing is correct: classified as
KindEventfd in FamilyIPC like its fd-creating siblings (eventfd2,
timerfd_create, inotify_init1, signalfd), flags captured from args[3]
per signalfd4(ufd, mask, sizemask, flags), and the return value left
Unclassified (it is an fd, not a byte count).
Add testdata fixtures FormatSignalfd4/FormatExitSignalfd4 (real Linux 7.0
tracepoint data) and a codegen lock-in test asserting the generated
handler reads flags from args[3], with negative guards against args[0]
(ufd), args[1] (mask pointer) and args[2] (sizemask).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audit of mkdirat(2) found the tracing implementation correct: the generated
BPF handler reads the pathname from args[1] (after the dirfd at args[0]),
while the sibling mkdir(2) reads from args[0] (no dirfd). Both are
KindPathname / FamilyFS with an UNCLASSIFIED return, consistent with
mknod/mknodat and docs/syscall-tracing-plan.md. The arg index is data-driven
from the kernel format via FieldNumber, so no source change was needed.
Add lock-in unit tests and real-format fixtures asserting:
- mkdirat captures the path from args[1], NOT args[0] (negative guard)
- mkdir captures the path from args[0]
- mkdirat/mkdir/mknodat share FamilyFS and KindPathname
- FieldNumber(pathname) = 1 for mkdirat, 0 for mkdir
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audit of mknod(2) found the tracing implementation already correct:
sys_enter_mknod captures the real pathname from args[0] (no dirfd),
while the sibling sys_enter_mknodat captures it from args[1] (after
dirfd). Both are FamilyFS path_events; both exits are ret_event
UNCLASSIFIED (int 0/-1). No code or doc changes were needed.
Add lock-in tests guarding this behavior against regressions:
- TestGenerateMknodMknodatHandlers asserts the generated BPF C reads
the path from args[0] for mknod and args[1] for mknodat.
- FormatMknodat/FormatExitMknodat testdata mirroring the real
tracepoint layout (dfd pushes filename to args[1]).
- mknodat rows added to the classify kind (KindPathname) and family
(FamilyFS) test tables, matching the existing mknod coverage.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audit of dup2(2) found the tracing implementation already correct and
consistent with its dup/dup3 siblings: dup2 is KindFd (a plain fd_event),
the enter handler captures ev->fd from args[0] (oldfd) per the KindFd
convention, it is in the FS family, and its exit returns the new fd
(newfd/-1) as a plain UNCLASSIFIED ret_event (never a byte-count
transfer). Unlike dup3 it carries no flags and clears O_CLOEXEC on the
duplicate, which the eventloop registerDup path already honors.
No discrepancies were found, so add a lock-in test (matching prior
audits) that asserts the generated BPF C for dup2 captures fd from
args[0] (not args[1]/newfd), emits an fd_event (not a dup3_event), wires
no flags, and classifies the exit UNCLASSIFIED. Adds FormatExitDup2
testdata to drive the exit handler assertions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audit of access(2) found the tracing implementation already correct:
FS family, KindPathname capturing the real path, and an UNCLASSIFIED
int 0/-1 ret_event on exit. access(2) captures its path from args[0]
(no dirfd), while siblings faccessat(2)/faccessat2(2) capture from
args[1] (dfd precedes the path). mage generate produces no diff and the
docs/integration coverage already match.
Add unit lock-in tests mirroring prior syscall audits:
- FormatAccess/FormatFaccessat tracepoint fixtures (real kernel formats).
- classify tests asserting both classify as KindPathname/"filename".
- family_test cluster asserting access/faccessat/faccessat2 stay FamilyFS.
- codegen test proving access reads ctx->args[0] while faccessat reads
ctx->args[1], guarding against a wrong-arg or dropped-path regression.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audit of init_module (man 2 init_module) confirmed the implementation is
correct: init_module(void *module_image, unsigned long len, const char
*param_values) is classified KindModule (null_event), capturing neither
an fd nor a path — param_values is a module-parameter string, not a
filesystem path. finit_module(int fd, ...) is classified KindFd via
field-based matching and captures fd = args[0]. Both syscalls live in the
Security family and match docs/syscall-tracing-plan.md.
No explicit finit_module test or init_module-vs-finit_module distinction
test existed, so add lock-in coverage:
- testdata.go: real-layout Format constants for (f)init_module enter/exit.
- classify_test.go: assert init_module=KindModule with no PathnameField
and finit_module=KindFd.
- codegen_test.go: assert generated BPF C for init_module captures no fd
and no filename/path, while finit_module captures fd = args[0].
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
utime(2) and utimes(2) change a file's access/modification times by a real
filesystem path (filename at args[0]). The path was already captured
(KindPathname), but both syscalls fell through to FamilyMisc instead of
joining their siblings utimensat/futimesat in FamilyFS. Add them to
fsSyscalls and regenerate; the only generated change is trace IDs
1034-1037 flipping FamilyMisc -> FamilyFS.
Lock-in coverage:
- family_test.go asserts utime/utimes/utimensat/futimesat are all FamilyFS.
- classify_test.go + FormatUtime fixture assert utime is KindPathname with
PathnameField "filename" (path captured even though it is a char* string,
unlike domain/host name args).
- New ioworkload scenarios utime-basic/utimes/enoent and integration tests
TestUtimeBasic/Utimes/Enoent verify the path is captured at runtime,
including on the ENOENT error path.
Docs updated: moved utime/utimes from Misc to FS in
docs/syscall-tracing-plan.md to keep the drift tests green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Audited epoll_create/epoll_create1 against man 2 epoll_create.
Implementation already correct: both classify as KindEventfd (fd-creating),
epoll_create(size) hardcodes flags=0 (no flags arg), epoll_create1(flags)
reads ctx->args[0], and exit captures the returned fd via ev->ret.
Add FormatEpollCreate1/FormatExitEpollCreate1 fixtures and
TestGenerateEpollCreate1HandlerUsesArg0Flags as the positive counterpart to
the existing TestGenerateEpollCreateHandlerUsesZeroFlags negative test,
asserting the enter handler captures args[0] as flags rather than 0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
epoll_create(size) was recording size (args[0]) as flags — hardcode to
0 since the syscall has no flags argument. pidfd_open(pid, flags) was
recording pid (args[0]) as flags — use args[1] instead.
Add test fixtures and codegen tests that verify the correct argument
indexes and reject the old wrong ones. Regenerate generated_tracepoints.c.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Amp-Thread-ID: https://ampcode.com/threads/T-019c7fec-eec9-706a-8338-3ce674802680
Co-authored-by: Amp <amp@ampcode.com>
|
|
Amp-Thread-ID: https://ampcode.com/threads/T-019c7f4e-cc5f-76f1-aaf0-dd7cbaabbb18
Co-authored-by: Amp <amp@ampcode.com>
|
