Import latest pidfile from NetBSD#618
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
✅ Files skipped from review due to trivial changes (3)
🚧 Files skipped from review as they are similar to previous changes (7)
WalkthroughThis PR refactors pidfile lifecycle management across dhcpcd to use dynamic path allocation, internal global state tracking, and improved cleanup semantics. Core pidfile operations are rewritten to support dynamic paths and reliable unlinking, new public accessors expose pidfile state, the daemon integrates capability rights limiting, and process fork/privilege-dropping cleanup is adjusted to work correctly with the new pidfile API. ChangesPidfile Lifecycle Refactoring
🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs:
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
configure (1)
1042-1070:⚠️ Potential issue | 🟠 Major | ⚡ Quick winExpand the pidfile feature probe to cover the full
util.hAPI, not justpidfile_unlock()The
configurepidfile test currently only compiles a call topidfile_unlock(), so it can succeed on platforms with partial pidfile support even though the build later relies on additionalutil.hsymbols (e.g.,pidfile_lock(),pidfile_read(),pidfile_fd(),pidfile_unremoveable()). Update the probe to reference the same set of pidfile functions the real code uses.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@configure` around lines 1042 - 1070, The probe only calls pidfile_unlock() but must exercise the full util.h pidfile API; update the generated _pidfile.c (the probe created in the configure fragment) so main() invokes pidfile_lock(), pidfile_unlock(), pidfile_read(), pidfile_fd() and pidfile_unremoveable() (e.g., call each and return a combined nonzero/zero result or cast to void where appropriate) so the compiler/linker will require all symbols; keep the existing include <util.h> and preserve the existing PIDFILE_LOCK / LIBUTIL detection flow using XCC and -lutil as currently implemented.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@compat/pidfile.c`:
- Around line 79-81: pidfile_readfd() currently returns -1 on strtoi() parse
failures without setting errno, which lets pidfile_clean() pick up a stale
errno; update pidfile_readfd (around the strtoi() call) to set errno = error
before returning -1 when strtoi() indicates a parse error (i.e., when error != 0
and not the ENOTSUP newline case), so callers like pidfile_clean() that read
errno after pid == -1 get the correct error code.
In `@src/privsep-linux.c`:
- Around line 340-342: Extend the seccomp allowlist in privsep-linux.c to
include the large-file/compat syscall variants used on 32-bit targets: add
conditional SECCOMP_ALLOW entries for __NR_ftruncate64, __NR__llseek (the compat
llseek), and where available __NR_lseek64 alongside the existing __NR_ftruncate
and __NR_lseek so pidfile.c's calls won't trigger SIGSYS; guard each new entry
with the appropriate `#ifdef` (e.g., `#ifdef` __NR_ftruncate64 / `#ifdef` __NR__llseek
/ `#ifdef` __NR_lseek64) next to the existing SECCOMP_ALLOW(__NR_ftruncate) and
SECCOMP_ALLOW(__NR_lseek) lines.
---
Outside diff comments:
In `@configure`:
- Around line 1042-1070: The probe only calls pidfile_unlock() but must exercise
the full util.h pidfile API; update the generated _pidfile.c (the probe created
in the configure fragment) so main() invokes pidfile_lock(), pidfile_unlock(),
pidfile_read(), pidfile_fd() and pidfile_unremoveable() (e.g., call each and
return a combined nonzero/zero result or cast to void where appropriate) so the
compiler/linker will require all symbols; keep the existing include <util.h> and
preserve the existing PIDFILE_LOCK / LIBUTIL detection flow using XCC and -lutil
as currently implemented.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0c6b5be4-e0b7-426b-bfb7-082be4144c6c
📒 Files selected for processing (11)
compat/pidfile.ccompat/pidfile.hconfiguresrc/bpf-bsd.csrc/bpf-linux.csrc/common.csrc/dhcpcd.csrc/dhcpcd.hsrc/privsep-control.csrc/privsep-linux.csrc/privsep.c
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Features improved chroot and sandbox support.
More portable, better support for chroot and sandboxes.
Adapt codebase.