Successful patches

No source files were changed. The collected signal is not strong enough for an upstream PostgreSQL patch: the sampled postmaster was sleeping in `epoll_wait`, not demonstrably spinning in PostgreSQL code.

The likely root cause of the collected perf, strace, and `/proc` evidence is a profiler classification mismatch, not a confirmed PostgreSQL busy loop. Fixer reported a “busy-poll” signal, but the process state was `S (sleeping)`, `wchan` was `do_epoll_wait`, strace captured only one `epoll_wait` line over 5 seconds, and total CPU across 9 postgres processes was only 0.4%. The hottest symbol was kernel memory-management code (`lru_gen_add_folio`), with additional samples in libcrypto and libc.

The relevant PostgreSQL code already uses the local event-waiting abstraction: the postmaster `ServerLoop()` waits through `WaitEventSetWait()`, backed by the platform `epoll_wait` path in `src/backend/storage/ipc/waiteventset.c`. Nearby conventions use `WaitEventSet`, latches, `ResetLatch(MyLatch)`, `TimestampDifferenceMilliseconds`, and `ereport`/`elog`; no generic replacement API is warranted. I found no prior Fixer patch for this finding in the Debian patch stack.

No patch was left because changing latch or timeout behavior from this evidence would be speculative and could delay postmaster shutdown, reload, child-exit handling, or connection acceptance. The expected effect of this proposal is to give an upstream-ready diagnosis and avoid an unsafe source change until repeated immediate wakeups or meaningful PostgreSQL CPU burn can be reproduced.

No source change is included. The collected perf, strace, and `/proc` evidence points at a sleeping `sshd-session` blocked in `poll()`, not a confirmed OpenSSH busy loop. The likely root cause is a profiler attribution mismatch or an external/kernel-side transient: the hot samples are kernel VM teardown symbols, while the traced userspace thread is in `restart_syscall` resuming `poll()`.

I followed the saved no-patch plan. I checked `README`, `README.md`, and the session/event-loop subsystem. Relevant local conventions are OpenBSD style plus helpers such as `ppoll()`, `ptimeout_*()`, `monotime()`, `ssh_packet_*()`, `sshbuf`, `xrecallocarray()`, and `fatal_f()`/`debug*_f()`. No relevant local helper or code path explains the evidence as an upstreamable `sshd-session` source bug.

Fixer observed `sshd-session: gis [priv]` and classified it as a possible runaway process, but the concrete collected signal is internally inconsistent with a userspace CPU loop: `/proc` reported state `S (sleeping)`, `wchan` was `poll_schedule_timeout.constprop.0`, strace captured only `restart_syscall(<... resuming interrupted restart_syscall ...>)`, and the sampled process had only `0.1%` max CPU. The perf hot path was in kernel symbols such as `vma_interval_tree_remove`, not in symbolized OpenSSH code.

The cautious code-level inference is that the process was waiting in the normal server/session event loop, and the available evidence is insufficient to identify an OpenSSH defect. This area is authentication/session-adjacent and timing-sensitive, so changing it without reproduced evidence would risk altering security-relevant behavior based on an unproven diagnosis.

I made no source change. This intentionally follows the plan in `plan-output.txt`; no code evidence proved a safe divergence from that plan. The expected effect is to avoid an unsupported upstream patch and leave a concise report suitable for human follow-up with stronger evidence, such as a symbolized backtrace or a reproducible busy-loop trace.

No source change is proposed. The collected sample points at the postmaster’s normal latch wait path, where a latch is PostgreSQL’s cross-process wakeup flag, rather than a confirmed CPU loop. Changing wait timing or signal handling here would be timing-sensitive and needs reproduced evidence.

Fixer collected a perf/strace/proc sample for `postgres` reporting an unresolved hot offset under `WaitEventSetWait()` and `PostmasterMain()`. The same evidence shows the process in `S (sleeping)` state, `wchan: do_epoll_wait`, and only `0.4%` max CPU across sampled postgres processes. The strace excerpt shows `epoll_wait()` sleeping for about 3.46 seconds, then a `SIGUSR1`-driven wakeup, a `SIGURG` latch notification, a signalfd read, and a child fork, which is consistent with the existing postmaster event loop.

The cautious inference is that the runaway-CPU classifier latched onto the postmaster wait path without enough source-level evidence of a busy loop. I inspected the local subsystem and found the relevant PostgreSQL helpers already in use: `WaitEventSetWait()`, `AddWaitEventToSet()`, `ResetLatch()`, `DetermineSleepTime()`, `ReserveExternalFD()`, `ReleaseExternalFD()`, `pqsignal()`, and `pgstat_report_wait_*()`. I followed the saved plan and made no source change.

The expected effect is that this proposal avoids an upstream-hostile timing patch in postmaster signal/latch handling until a reproducible loop or resolved hot source line is available.

No source change. The collected perf, strace, and `/proc` evidence points to an `sshd-session` process sleeping in `poll`, with sampled time attributed to Linux IMA, the kernel Integrity Measurement Architecture. That is not enough evidence for an upstream OpenSSH code change, especially in session/timing code.

I followed the saved plan in `plan-output.txt` and did not change course.

The collected signal was a Fixer runaway-process report for `sshd-session`, but the details do not show a reproduced OpenSSH userspace loop. The process state was `S (sleeping)`, `wchan` was `poll_schedule_timeout.constprop.0`, strace captured only `restart_syscall(<... resuming interrupted poll ...>)`, total target CPU was reported as `0.1%`, and the hot sampled symbol was kernel-side `ima_file_free`.

The cautious inference is that this sample caught a normal server session process blocked in the OpenSSH event loop, while perf attributed sampled kernel time to IMA. The relevant OpenSSH code already uses local helpers and conventions for this path: `serverloop.c` blocks in `ppoll()` through `wait_until_can_do_something()`, channel state is prepared by `channel_prepare_poll()`, poll deadlines use `ptimeout_*`, allocations use `xcalloc`/`xrecallocarray`, and fatal paths use `fatal_f`/`fatal_fr`.

No code change was made. The expected effect is no runtime change; this should be treated as a no-patch diagnosis for human review until a reproducible high-CPU `sshd-session` case or a direct OpenSSH userspace loop is captured.

No source change is proposed. The collected data points to `sshd-session` sleeping in the session event loop’s `ppoll()` wait, not to a reproduced OpenSSH userspace spin.

Fixer collected a runaway-process signal for `/usr/lib/openssh/sshd-session`, but the supporting perf, strace, and `/proc` data do not identify an OpenSSH bug. The process state was `S (sleeping)`, `wchan` was `poll_schedule_timeout.constprop.0`, strace saw only `restart_syscall(<... resuming interrupted poll ...>)` over 5 seconds, and the sampled `sshd-session` process group showed only 0.3% CPU. The hottest symbols were kernel-side, including `userfaultfd_unmap_complete`, not resolved OpenSSH frames.

The likely root cause is therefore not a confirmed `sshd-session` userspace loop. The cautious inference is that the profiler attributed kernel work to a process blocked in `poll`, or captured a transient signal without enough symbolized evidence to connect it to OpenSSH source.

I followed the saved plan’s no-patch direction. I did change the confidence label from the plan’s `observed` to `inferred` because the final authoring rules classify profiler/strace-only evidence without a reproduced failure as indirect. No source change was made because this area is security-sensitive session/authentication code, and changing `serverloop.c` timing or readiness behavior without a reproducer would be unsafe.

The relevant local code already uses OpenSSH’s existing helpers and conventions: `ppoll()` with `ptimeout_*` deadline helpers, `monotime`, `ssh_signal`, `fatal_f`/`fatal_fr`, `debug*_f`, and `xcalloc`/`xrecallocarray`. The expected effect is to avoid an upstream-unready speculative patch and leave a diagnosis suitable for a human report asking for a symbolized backtrace or reproducible high-CPU session.

No source change is proposed. The likely root cause of the Fixer signal is a misclassified idle `sshd-session` monitor process, not an OpenSSH userspace busy loop: the process was sleeping in `poll`, `strace` saw only a resumed `poll` syscall, and sampled CPU for all matching processes was very low.

The collected signal was a runaway-process report for `sshd-session`, with a perf sample mentioning kernel memory-management work and a backtrace ending in `poll`. The `/proc` evidence says the process was in state `S (sleeping)`, its wait channel was `poll_schedule_timeout.constprop.0`, and a 5-second `strace` captured only `restart_syscall(<... resuming interrupted poll ...>)`.

The cautious inference is that this is an idle privileged session monitor sleeping in OpenSSH’s normal server event loop, not a demonstrated CPU-hot userspace loop. The nearby code in `serverloop.c` intentionally waits in `ppoll()` through `wait_until_can_do_something()`, using local helpers and conventions such as `ptimeout_*`, `channel_prepare_poll`, `ssh_packet_*`, `fatal_f`/`fatal_fr`, `debug*`, `xcalloc`, and `sshbuf`.

I made no code change. This follows the saved plan’s no-patch direction; I classify the final evidence as `inferred` rather than the plan’s `observed` because this authoring pass explicitly treats profiler/strace-only evidence without a reproduced failure as indirect and not pull-request-ready. The expected effect is that upstream receives a diagnosis instead of a speculative change to authentication/session/timing-sensitive code.

Only `README.md` was present among the requested contribution/style documents; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` file was found.

No source change was made. The collected signal points at PostgreSQL’s normal postmaster wait path, not a demonstrated busy loop.

The postmaster uses `WaitEventSet`, PostgreSQL’s cross-platform wait abstraction, with `Latch` wakeups and Linux `epoll_wait` underneath. The evidence shows the process sleeping in that path rather than repeatedly waking.

Fixer reported a likely busy poll loop in `postgres`, with a backtrace through `WaitEventSetWait()` and `epoll_wait()`, and a kernel hot symbol `folio_add_new_anon_rmap`. The `/proc` evidence says the sampled postmaster was in state `S (sleeping)`, `wchan` was `do_epoll_wait`, total CPU was about 0.4%, and the five-second strace captured only one `epoll_wait` line, which is consistent with a blocking wait rather than a spin.

The likely root cause is a profiler/classifier false positive: repeated samples found the postmaster in the normal idle wait syscall, while the CPU attribution was in kernel memory-management code rather than PostgreSQL source. The relevant code path is `ServerLoop()` using `ConfigurePostmasterWaitSet()`, `WaitEventSetWait()`, and `ResetLatch()`; nearby code already uses PostgreSQL’s local helpers and conventions such as `WaitEventSet`/`Latch`, `elog`/`ereport`, `MemoryContextAllocZero`, and `AcquireExternalFD`/`ReleaseExternalFD`.

I made no code change because changing wait-loop or timing behavior from this evidence would be speculative and could regress postmaster responsiveness. The expected effect of this diagnosis is to avoid an unsafe upstream patch and give maintainers a concrete bug-report basis: collect evidence of rapid repeated `epoll_wait` returns, latch drain failures, or sustained CPU before changing PostgreSQL source.

No source change was made. The collected evidence points at PostgreSQL's Serializable Snapshot Isolation pre-commit check, but the runtime traces do not establish a reproducible busy loop or correctness bug.

The likely root cause from the collected evidence is a weak or transient profiler attribution rather than a confirmed runaway loop. Fixer recorded `PreCommit_CheckForSerializationFailure` as the only hot symbol, but the sampled postmaster was in state `S (sleeping)`, `/proc` showed `wchan` as `do_epoll_wait`, strace showed a long `epoll_wait()` interrupted by normal postmaster signaling, and the profile target reported only 0.4% total CPU across postgres processes.

`PreCommit_CheckForSerializationFailure` is part of Serializable Snapshot Isolation, PostgreSQL's mechanism for detecting dangerous read/write dependency structures before a serializable transaction commits. The code walks SSI conflict lists under `SerializableXactHashLock` using established local helpers and conventions such as `dlist_foreach`, `dlist_container`, `LWLockAcquire/Release`, `ereport`, and `Sxact*` flag checks. I did not find a bounded, correctness-preserving source change that follows from the evidence.

No code change was made. The expected effect is to avoid landing a speculative serializability change until an upstream report can include a workload or trace that actually shows excessive time in the SSI pre-commit scan.

I followed the saved plan and did not change course. I checked `README.md`, `src/backend/storage/lmgr/README-SSI`, and `src/test/isolation/README`; no `CONTRIBUTING` or `HACKING` file was present in the workspace scan. No relevant prior Fixer or Debian patch touched this subsystem.

No source change. The collected signal points at a sleeping `sshd-session` process blocked in `poll`, with PAM/SELinux and kernel samples nearby, but it does not identify a reproducible OpenSSH loop or unsafe state transition.

The collected signal was `sshd-session: gis [priv]` with a 5-second `strace` showing only `restart_syscall(<... resuming interrupted poll ...>)`, `/proc` state `S (sleeping)`, and `wchan` `poll_schedule_timeout.constprop.0`. The perf samples included kernel VMA work and an unresolved `pam_selinux.so` offset, while reported CPU was only `0.7%` across three processes.

The cautious code-level inference is that the process was likely in a normal OpenSSH wait point, such as the privileged monitor’s `poll()` loop or the server/channel `ppoll()` loop, not a demonstrated busy userspace loop. This touches PAM/session setup, authentication-adjacent cleanup, and SELinux context handling, so a speculative source change would be security-sensitive without reproduced evidence.

I made no source change and followed the saved plan. Relevant upstream conventions checked include `fatal_f`/`error_f` logging, `xmalloc`, `sshbuf`, `atomicio`, `ptimeout_*`, and Linux portability wrappers such as `ssh_selinux_enabled()`. `README.md` was the only requested contribution/style document found.

The expected effect is that no OpenSSH behavior is changed until a concrete, reproducible OpenSSH-side defect is available.

No source change is proposed. The likely root cause from the collected perf, strace, and `/proc` evidence is an idle or interrupted `poll(2)` wait in `sshd-session`, not a demonstrated OpenSSH busy loop: the sampled process was sleeping, `wchan` was `poll_schedule_timeout.constprop.0`, and strace saw only a restarted interrupted poll.

The collected signal was a Fixer runaway-process report for `sshd-session`, with kernel hot symbols such as `__memcg_slab_free_hook`, a userspace backtrace ending in `poll()`, process state `S (sleeping)`, and only one strace line: `restart_syscall(<... resuming interrupted poll ...>)`.

The cautious code-level inference is that the sample is consistent with normal blocking waits in OpenSSH’s session/monitor machinery, not a source-identified CPU loop. Nearby code uses `monitor_read()` waiting in `poll(..., -1)` for monitor IPC, and `server_loop2()` waiting in `ppoll()` through the local `ptimeout_*`, `ssh_packet_*`, and `channel_*` helpers. I also checked `README.md`; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` guidance was present.

I made no code change. This follows the saved plan except for classifying confidence as `inferred` rather than `observed`, because the current evidence is profiler/strace/proc-state evidence without a reproduced OpenSSH failure or symbolized source-level loop. Since `sshd-session` covers authentication, credentials, privilege separation, and timeout behavior, leaving a source diff without reproduced evidence would be security-sensitive and not upstream-ready.

The expected effect is that this proposal remains a maintainer-usable diagnosis/report instead of introducing a speculative change to authentication/session control flow.

No source change is proposed. The collected evidence points at an `sshd-session` process sleeping in the normal poll wait path, not at a reproduced OpenSSH userspace loop. Session timeout and authentication-adjacent code is security-sensitive, so changing it without a reproducible failure would not be upstream-ready.

Fixer collected a short perf/strace/proc sample for `sshd-session`: the process state was `S (sleeping)`, `/proc` wait channel was `poll_schedule_timeout`, strace showed only `restart_syscall`, and the hottest sampled symbol was kernel-side `__free_one_page`. The likely root cause is a profiler attribution false positive or unrelated kernel memory activity while `sshd-session` was blocked in `poll(2)`/`ppoll(2)`, rather than a proven OpenSSH busy loop.

The relevant OpenSSH code path is `serverloop.c:wait_until_can_do_something()`, which intentionally sleeps in `ppoll()` after preparing channel file descriptors and deadlines. Nearby code already uses local helpers and conventions: `ptimeout_*()` and `monotime*()` for poll deadlines, channel/packet helper APIs, `xrecallocarray()` for allocation, and OpenBSD-style `fatal_f()`/`debug*()` logging. `README.md` points contributors to OpenBSD style; no separate `CONTRIBUTING`, `HACKING`, `docs/`, or `dev-docs/` files were present.

Specific change made: none. This follows the saved plan; I did not change course. The expected effect is to avoid an unsafe, speculative patch in authentication/session timing code until a maintainer or follow-up investigation can capture a reproducible high-CPU userspace stack.

No source change is proposed. The collected signal points at an `sshd-session` process sleeping in the normal `poll`/`ppoll` wait path, not at a confirmed OpenSSH userspace busy loop. Because this is server session and timing behavior, changing it without a reproduced failure would be unsafe.

Fixer collected a perf/strace/proc snapshot for `/usr/lib/openssh/sshd-session` labeled as runaway CPU. The concrete evidence is mixed: the process state was `S (sleeping)`, `wchan` was `poll_schedule_timeout.constprop.0`, strace captured only one `restart_syscall` over 5 seconds, and the target CPU total was only `0.9%` across three processes.

The likely root cause is a false-positive or under-specified profiler attribution around an interrupted `poll` wait, not a demonstrated OpenSSH loop. In OpenSSH, the relevant post-auth session loop in `serverloop.c` intentionally waits in `ppoll` after building descriptors through `channel_prepare_poll()` and timeouts through the local `ptimeout_*` helpers in `misc.c`.

I followed the saved plan and made no source change. The touched area would be security-sensitive because it involves authenticated server session handling and timeout/keepalive behavior, and the failure was not reproduced. The expected effect is that this proposal becomes an upstream-ready diagnosis/report rather than a speculative patch.

Likely root cause: the collected signal appears to be a profiler misclassification, not a demonstrated busy loop. The evidence shows `sshd-auth` sleeping in a Unix socket read, then doing the normal authentication failure delay path before the peer resets the connection.

No source patch is included. The implicated code is authentication and timing/throttling behavior, so changing it without reproduced evidence would be unsafe.

Fixer collected a short `sshd-auth` profile labeled as a likely busy-poll loop, with syscalls including `clock_nanosleep`, `write`, and `ppoll`. The same evidence reports only `0.8%` CPU, process state `S (sleeping)`, `wchan=unix_stream_read_generic`, and a strace ending in `ECONNRESET` followed by process exit.

The cautious code-level inference is that the `clock_nanosleep` corresponds to OpenSSH’s authentication failure timing mitigation in `auth2.c`, while the blocking dispatch path goes through `ssh_dispatch_run_fatal()`, `ssh_packet_read_seqnr()`, and `ppoll()`/`read()`. Monitor/log socket I/O already uses the local `atomicio()` helper; poll deadline helpers are `ptimeout_*`. Project guidance points to OpenBSD style.9 and existing OpenSSH wrappers such as `xmalloc`, `fatal_f`/`debug3_f`, `atomicio`, and compatibility APIs.

I made no source change. This follows the saved plan; the code did not prove the plan wrong. The expected effect is no runtime behavior change and no speculative alteration of authentication timing/security behavior without reproduced evidence.

No source change. The collected profile points at an `sshd-session` privileged monitor blocked in `poll(2)`, which is the expected wait path for post-authentication monitor requests, not a demonstrated OpenSSH busy loop.

Fixer collected perf, strace, and `/proc` evidence for `sshd-session: gis [priv]`: kernel samples included `unmap_page_range`, the backtrace reached `poll()`, strace saw only a resumed `restart_syscall`, `/proc` reported `S (sleeping)`, and `wchan` was `poll_schedule_timeout.constprop.0`.

The cautious code-level inference is that this is the normal privileged monitor process in `monitor_child_postauth()`, where `monitor_read()` waits indefinitely in `poll()` for monitor or log messages. I did not find evidence of repeated immediate wakeups, `POLLNVAL`, or a userspace loop in `monitor.c`, `sshd-session.c`, `serverloop.c`, or `channels.c`.

I followed the saved plan and did not leave a source diff. A source patch would be speculative here because the evidence is profiler/trace-derived and does not identify an OpenSSH bug. Relevant local conventions inspected include OpenSSH’s `fatal_f`/`debug*` logging, `ssh_signal`, `sshbuf`, `atomicio`, `xrecallocarray`, and `ptimeout_*` helpers; no new API was introduced.

The expected effect is that this proposal remains an upstream bug-report-quality diagnosis instead of landing a risky monitor-path behavior change without a reproduced failure.

No source changes. The collected signal points at assertion-only tuple descriptor validation overhead, not at a confirmed PostgreSQL runtime bug. `verify_compact_attribute()` checks that a compact attribute, PostgreSQL's cached small copy of tuple-column metadata, still matches the full `FormData_pg_attribute` after descriptor changes.

The likely root cause from the collected perf, strace, and `/proc` evidence is a misleading runaway-process classification. Perf sampled `verify_compact_attribute()` as 7.45% of the hot path, but the target postmaster was in state `S (sleeping)`, `wchan` was `do_epoll_wait`, total CPU was about 0.5%, and a 5-second strace captured only one blocked `epoll_wait(8` call. That does not show a busy poll loop.

The code-level inference is that the sampled symbol is assertion-build tuple descriptor checking: `TupleDescCompactAttr()` calls `verify_compact_attribute()` only under `USE_ASSERT_CHECKING`, and the verifier intentionally catches callers that mutate `FormData_pg_attribute` without calling PostgreSQL's local helper `populate_compact_attribute()`.

I followed the saved plan and made no source change. Weakening or throttling this verifier from profiler-only evidence would hide real assertion failures without fixing a demonstrated bug. The expected effect is that no upstream patch is proposed until stronger evidence identifies a specific missed `populate_compact_attribute()` call or a reproducible runtime loop.

Contribution/style context checked: `.github/CONTRIBUTING.md`, `README.md`, and local tuple descriptor code. Relevant local conventions are `Assert`, `elog`, `palloc`, `TupleDescCompactAttr()`, and `populate_compact_attribute()`; no new helper/API was introduced.

No source change is proposed. The collected signal points at an idle PostgreSQL postmaster blocked in the wait-event set, not at a proven upstream busy loop.

Fixer collected profiler, strace, and `/proc` evidence for `/usr/lib/postgresql/18/bin/postgres` and classified it as a possible busy poll loop. The stack shows `PostmasterMain()` inside `WaitEventSetWait()` and then `epoll_wait()`, but the process state is `S (sleeping)`, `wchan` is `do_epoll_wait`, strace saw only one `epoll_wait` line over five seconds, and sampled CPU was low (`max_cpu_percent` 0.8 for the target process, 1.0 total across postgres processes).

The cautious code-level inference is that this is likely a normal postmaster wait, or an indirect kernel/profile artifact, rather than a PostgreSQL loop returning immediately from `epoll_wait()`. The local subsystem conventions support that reading: `src/include/storage/latch.h` documents PostgreSQL’s latch protocol, and `src/backend/postmaster/postmaster.c` uses the existing `WaitEventSetWait()`, `SetLatch(MyLatch)`, `ResetLatch(MyLatch)`, `DetermineSleepTime()`, and `ConfigurePostmasterWaitSet()` helpers rather than raw polling.

I made no source change because the evidence is indirect and locally unreproduced. The expected effect is to avoid landing a speculative upstream patch that could disturb PostgreSQL’s race-sensitive latch and wait-event behavior without a demonstrated bug.

This follows the saved plan; I did not change course.

`dockerd` restarts the containerd task event stream after subscription errors. When containerd is already serving, the old code immediately spawned a replacement goroutine, so repeated transient subscription failures could retry without any pause. Keep the restart in the same goroutine and wait briefly before resubscribing.

Fixer observed `dockerd` running with `--containerd=/run/containerd/containerd.sock`; the collected perf/strace/proc evidence showed a sleeping daemon with many futex waits and classified the profile as socket churn. This failure was observed by Fixer and not independently reproduced.

The cautious code-level connection is the libcontainerd event stream, which is the daemon’s subscription to containerd task events. On a non-canceled subscription error, `processEventStream` waited for containerd readiness and then immediately started another `processEventStream` goroutine. If the readiness probe succeeds while subscriptions keep failing transiently, that path can repeatedly resubscribe to the containerd socket without a bounded delay.

I changed that path to return through a one-shot helper and retry in the same goroutine after a 100 ms context-aware delay. I also added a short comment explaining the invariant: a successful readiness probe must not allow immediate resubscribe churn. The code follows nearby timer patterns and existing `containerd/log` usage; syscall wrappers such as `engine/internal/unix_noeintr` and netlink helpers such as `engine/internal/nlwrap` do not fit this gRPC/containerd subscription path.

The expected effect is to reduce rapid containerd socket retry churn after transient event subscription failures while preserving cancellation and normal restart behavior.

`auth2.c` adds a small per-user failed-authentication delay before sending an authentication failure. If authentication has already taken longer than that requested delay, return immediately instead of doubling the delay until it exceeds the elapsed time.

This keeps the intended minimum-delay behavior without adding seconds of extra sleep after a slow backend or monitor round trip.

Fixer observed `sshd-auth` with trace evidence: `/proc` showed the process sleeping in `unix_stream_read_generic`, perf attributed sampled time to socket receive handling, and strace showed a `read(3, ...)` taking about 2.055919s followed by `clock_nanosleep(...)` for about 2.025614s. This failure was observed by Fixer and not independently reproduced as a live sshd session.

The cautious code-level cause is `ensure_minimum_time_since()` in `auth2.c`: after failed non-`none` authentication, it doubled a requested 5 to 9.2ms per-user delay until it exceeded elapsed authentication time. If authentication had already taken about two seconds, that could compute another multi-second sleep.

The change makes `ensure_minimum_time_since()` return when elapsed time already satisfies the requested minimum delay, and only sleep for the remaining difference when authentication was faster than the floor.

The expected effect is to avoid amplifying slow failed-authentication work into an additional long timer sleep while keeping the intended minimum failed-auth delay.

No source patch was made. The collected signal points at a sleeping `sshd-session` process blocked in `poll`, not at a confirmed OpenSSH busy loop, so a source change would be speculative rather than upstreamable.

Fixer reported `sshd-session` as a runaway process, but the collected signal is indirect: the process was `S (sleeping)`, `wchan` was `poll_schedule_timeout`, `strace` captured only one `restart_syscall` resuming `poll`, and the hottest samples were kernel memory-management symbols. That is more consistent with a process blocked in OpenSSH’s event loop than with a demonstrated userspace spin.

The relevant server paths already use OpenSSH’s local helpers and conventions: `ptimeout_*`, `monotime()`, `channel_prepare_poll()`, `channel_after_poll()`, `ssh_signal()`, `xcalloc()`/`xrecallocarray()`, `atomicio()`, and `fatal_f`/`debug*_f`. I found `README.md` but no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The saved plan was followed; the code did not provide stronger evidence that would justify changing course.

No code change was made. The expected effect is that we avoid landing a speculative event-loop patch without a symbolized hot userspace stack, repeated tight syscall trace, or reproducible session CPU spin.

No source patch is proposed. The collected evidence points to PostgreSQL’s normal postmaster idle wait path, not to a confirmed busy loop.

The collected signal was a `postgres` postmaster sampled in `WaitEventSetWait()` -> `epoll_wait()`. `/proc` reported the process as `S (sleeping)` in `do_epoll_wait`, strace captured only one `epoll_wait` line over five seconds, and total sampled CPU was only `0.5%`.

The cautious inference is that the profiler classified a normal blocking wait as a busy poll. In PostgreSQL, a `WaitEventSet` is the local helper used to wait on latches and sockets together; the inspected postmaster loop already uses `ConfigurePostmasterWaitSet()`, `WaitEventSetWait()`, `DetermineSleepTime()`, `ResetLatch()`, and socket wrappers such as `closesocket()`. I did not find a code-level cause, uncleared event, zero-timeout loop, or prior Fixer patch to improve or replace.

Because the evidence is indirect and I could not gather stronger observed or reproduced evidence in this container, I made no source change. The expected effect is that we avoid landing a speculative upstream PostgreSQL patch that could perturb connection acceptance, reload/shutdown handling, or child-exit processing in the postmaster idle loop.

Failed user authentication uses a timing pad to reduce username and backend timing leaks. When backend work already exceeds the requested pad, cap the scaled delay target at `MAX_FAIL_DELAY_SECONDS` so slow failed-auth paths do not add avoidable sleep beyond the intended maximum.

Fixer observed an `sshd-auth` pre-authentication child with strace samples reaching `clock_nanosleep()` after failed auth traffic, while `/proc` showed the process sleeping with negligible CPU. This failure was observed by Fixer and not independently reproduced.

The likely code-level cause is `auth2.c:ensure_minimum_time_since()`: it checked `MAX_FAIL_DELAY_SECONDS` before scaling the failed-auth timing pad upward, but not after that scaling. I kept the existing timing-pad behavior, clamped the scaled target with OpenSSH’s existing `MINIMUM()` helper, and returned without sleeping when elapsed auth work has already reached the cap. The expected effect is to preserve the timing mitigation while preventing slow failed-auth backends from adding extra sleep past the maximum delay target.

For upstream style, I checked the available project docs (`README.md`; no `CONTRIBUTING`, `HACKING`, or `README-hacking` found) and kept to nearby auth2 conventions: `monotime_double()`, `debug3_f()`, direct `nanosleep()`, and `misc.h` helpers. The review finding was addressed by removing generated regress artifacts from validation; the final patch file set is only `auth2.c`.

No source change. The collected signal shows `sshd-session` sleeping in `poll()`/`restart_syscall`, not a symbolized OpenSSH busy loop. The safest upstreamable result is a diagnosis: collect symbolized stack or runtime wakeup evidence before changing the server event loop.

The collected signal is a Fixer perf/strace report for `/usr/lib/openssh/sshd-session`: a stripped backtrace in `poll()`, kernel `wchan` at `poll_schedule_timeout`, one `restart_syscall` line over 5 seconds, and only `0.3%` sampled total CPU. The referenced raw artifact directory was absent, so the richer trace files could not be re-read.

The cautious code-level inference is that the process was blocked in OpenSSH’s normal session event loop, not proven to be spinning in OpenSSH source. In `serverloop.c`, the server uses `channel_prepare_poll()`, `channel_after_poll()`, `ptimeout_*`, `monotime()`, `ssh_packet_*`, and `ppoll()` in the expected local style. I found no safer bounded source change that connects causally to the collected evidence.

I followed the saved plan and left no source diff. The expected effect is avoiding a speculative upstream patch until a symbolized backtrace, repeated wakeup trace, or reproducible test ties the alert to a specific OpenSSH control-flow defect.

`channel_prepare_pollfd()` builds the `pollfd` array used by the SSH channel event loop. For channel socket fds, it computed the requested `POLLIN`/`POLLOUT` event mask but stored zero in `pollfd.events`, so `ppoll()` would not wait for the readiness the channel handlers expected.

Store the computed event mask for socket fds, matching the existing `rfd`, `wfd`, and `efd` paths.

Fixer observed `sshd-session` processes with profiler samples in kernel conntrack, `strace` showing `restart_syscall`, and `/proc` state showing the process sleeping in `poll_schedule_timeout`. I did not independently reproduce that production signal.

The likely root cause in the channel event loop is that socket-only channel fds were registered in the `pollfd` array with `events = 0` even after the code computed `POLLIN` or `POLLOUT` from `SSH_CHAN_IO_SOCK_R/W`. In OpenSSH’s channel subsystem, `io_want` records which fd readiness a channel needs before its post-poll handler can run.

The patch changes the socket fd poll setup to store `ev`, the same computed event mask used by the other fd slots. The expected effect is that listener and connecting socket channels can actually wake `ppoll()` for the readiness they requested, preventing this event-loop path from parking a session without arming the socket events it needs.

No new helpers were needed. The touched subsystem already uses `xrecallocarray()` for pollfd allocation, `fatal_f()`/`debug3()` logging, and `ptimeout_*()` for `ppoll()` timeouts; this patch follows the existing local pattern. I checked `README.md`; no `CONTRIBUTING`/`HACKING` docs were present.

No source change is included. The collected evidence points to an `sshd-session` process blocked in the normal server event loop, not to a demonstrated userspace busy loop. A patch to OpenSSH’s channel or packet loop would be speculative without a reproducible zero-timeout poll, repeated wakeup, or CPU-hot userspace frame.

The collected signal was a Fixer profiler report for `sshd-session`: the process state was `S (sleeping)`, `/proc` showed `wchan=poll_schedule_timeout`, strace captured only `restart_syscall(<... resuming interrupted poll ...>)` over 5 seconds, and the sampled process set used about 0.1% CPU. The perf hot symbols were kernel memory-management symbols, not resolved OpenSSH frames.

The cautious code-level inference is that the process was in OpenSSH’s normal post-auth event loop: `server_loop2()` prepares channel file descriptors with `channel_prepare_poll()`, uses the local `ptimeout_*` helpers for deadlines, and sleeps in `ppoll()`. I found relevant local conventions and helpers: `ptimeout_*` for poll deadlines, `xrecallocarray()` for pollfd allocation, `ssh_packet_*` wrappers for packet state, and `fatal_f`/`error_f`/`logit` for diagnostics. `README.md` documents the autoconf/make build flow.

I did not make a source change because the evidence is profiler/trace-adjacent but does not identify a source defect. This follows the saved plan in `plan-output.txt`; I did not change course. The expected effect is no behavioral change: this avoids landing an upstream patch that could alter SSH session I/O semantics without a demonstrated bug.

The likely root cause is not an OpenSSH userspace runaway. The sampled process was `sshd-session: gis [priv]`; in OpenSSH privilege separation, the privileged monitor is a long-lived helper process that waits for requests from the unprivileged session process.

No source change is proposed. The evidence shows a sleeping process in `poll`/`restart_syscall`, with hot samples in kernel netlink and `libnss_systemd`/PAM-related libraries rather than symbolized OpenSSH code.

The collected signal was a Fixer perf/strace/proc sample for `sshd-session`: `State: S (sleeping)`, `wchan: poll_schedule_timeout.constprop.0`, one strace line resuming an interrupted `poll`, and top samples in `__netlink_lookup`, `libnss_systemd.so.2`, and other kernel/systemd/PAM-adjacent locations.

The cautious inference from the code is that this matches OpenSSH’s documented post-authentication privilege-separation monitor, not a proven OpenSSH busy loop. `README.privsep` documents the extra privileged monitor process per login session, and `monitor_child_postauth()` intentionally calls `monitor_read()` in a long-lived loop where `monitor_read()` blocks in `poll(..., -1)` until monitor or log descriptors are readable.

I made no source change. For this refinement round, I addressed the review finding by reverting the unintended generated-file drift in `aclocal.m4`, `config.h.in`, and `configure`, so `## Git Add Paths` now matches the clean tree. The expected effect is to avoid shipping a speculative upstream patch against security-sensitive privilege-separation behavior until stronger OpenSSH-owned evidence exists.

Style/context checked: `README.md`, `README.privsep`, `monitor.c`, and `auth-pam.c`. No `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` entry was found. Relevant local conventions include OpenBSD-style C, `fatal_f`/`error`/`debug`, `sshbuf`, `atomicio`, and monitor helpers such as `monitor_permit()` and `monitor_read()`.

No source change was made. The collected perf, strace, and `/proc` evidence points more strongly to a normally idle postmaster blocked in its wait-event abstraction than to a PostgreSQL busy loop.

The relevant upstream helpers are `WaitEventSetWait()`, `AddWaitEventToSet()`, `ResetLatch()`, `TimestampDifferenceMilliseconds()`, and `ereport()`/`elog()`. Contribution/style pointers checked: `README.md`, `.github/CONTRIBUTING.md`, and `src/DEVELOPERS`.

The collected signal is a postmaster backtrace in `WaitEventSetWait()` -> `epoll_wait()`, `/proc` state `S (sleeping)`, wait channel `do_epoll_wait`, one captured `epoll_wait` line over a 5 second strace, and total sampled CPU around 0.5%.

The cautious code-level inference is that this is the postmaster’s normal event wait path, not a demonstrated spin. `ServerLoop()` computes a bounded sleep, normally up to 60 seconds, and waits through PostgreSQL’s `WaitEventSetWait()` compatibility layer, which uses Linux `epoll_wait()` in this build. The evidence does not show repeated immediate returns from `epoll_wait()` or a violated latch/socket invariant.

I made no source change and followed the saved no-patch plan. An inferred source patch here would risk changing postmaster signal/latch behavior without a reproduced or directly observed PostgreSQL defect. The expected effect is to avoid landing a speculative upstream patch and leave a concrete diagnosis for a future bug report or reproduction attempt.

Change the SMTP server command reader so an overlong SMTP command is rejected and the session is closed instead of draining all excess input first. The command path now uses Postfix’s existing `smtp_get()`/`VSTREAM` helpers, but leaves excess command input unread so the main loop can stop parsing that connection. SASL continuation reads keep the old drain behavior because that caller can recover from an authentication failure.

Fixer observed `smtpd` with a backtrace in `smtp_get()` through `vstring_get_flags_bound()` and `timed_read()`, with perf samples in `gettimeofday()` and kernel allocation paths; this was observed by Fixer and not independently reproduced.

The cautious code-level inference is that the SMTP command reader’s `SMTP_GET_FLAG_SKIP` path can spend extra time draining malformed overlong command input to a newline before returning failure. I changed the normal SMTP command read path to stop at `line_length_limit`, return failure, send `500 5.5.2 Error: command line too long`, and close the session. I kept `smtpd_chat_query_limit()` draining excess input for SASL continuation lines, where the caller-specific limit is part of a recoverable AUTH exchange.

The expected effect is to bound work on malformed overlong SMTP commands and avoid continuing to read from a client after the server already knows the command cannot be parsed. I added a short source comment explaining the unread-excess invariant.

During daemon startup, the container restore paths used a semaphore to limit active startup work, but each loop still created one goroutine per container before acquiring that semaphore. A semaphore is a concurrency limiter; acquiring it inside each worker limits running work, but not the number of goroutines parked waiting for a slot.

This adds a small helper that acquires the existing startup semaphore before starting the worker goroutine, then releases it with `defer`. The startup limit now bounds both active work and goroutines waiting for startup work. I followed the plan, except I intentionally left the legacy-link restart phase’s goroutine creation order unchanged because those workers can wait on child container notifications.

Fixer observed `dockerd` running with 185 threads, low CPU, process state `S (sleeping)`, a futex-heavy stack, and strace samples dominated by futex waits. This failure signal was observed by Fixer and not independently reproduced.

The cautious code-level inference is that daemon startup can contribute to this wait-heavy shape: several restore loops in `engine/daemon/daemon.go` create a goroutine for every container and only then acquire the startup semaphore. That means a large container set can still create many goroutines blocked on the semaphore, even though `adjustParallelLimit` is meant to cap startup parallelism.

The patch keeps the existing local patterns, specifically `adjustParallelLimit`, `sync.WaitGroup`, and `golang.org/x/sync/semaphore`. It adds `startParallelStartupTask`, which acquires the semaphore before launching each independent startup worker. I added a short source comment explaining the invariant being preserved.

The expected effect is fewer startup goroutines parked in semaphore/futex waits when many containers are restored or restarted, without increasing the amount of concurrent startup work.

`channel_prepare_pollfd()` builds `pollfd` entries, the file descriptor/event pairs passed to `poll`/`ppoll`, for each channel. For a channel whose `sock` fd is separate from its read fd, the code computed the requested `POLLIN`/`POLLOUT` mask but then stored zero in `pfd[p].events`.

Store the computed event mask instead, matching the read, write, and extended-fd branches. This lets socket-backed channel states such as listeners and nonblocking connects wake the channel loop when their socket is ready.

Fixer observed an `sshd-session` with event-loop wakeup signals: the collected `/proc` and strace evidence showed the process sleeping in `poll`/`restart_syscall`, while perf attributed sampled CPU to the kernel transmit path. That failure was observed by Fixer and not independently reproduced.

The cautious code-level connection is that `sshd-session` waits for channel activity through `channel_prepare_pollfd()`, and this function was arming separate channel socket descriptors with no requested events. If a channel wanted `SSH_CHAN_IO_SOCK_R` or `SSH_CHAN_IO_SOCK_W`, the corresponding `pollfd` existed but could not report readiness.

The patch changes the separate-`sock` branch to assign `pfd[p].events = ev`, where `ev` is the already-computed `POLLIN`/`POLLOUT` mask. The expected effect is that socket-backed channel work can wake promptly through the normal channel poll path instead of depending on unrelated loop wakeups. No new helper APIs were needed; the change follows the existing `channel_prepare_pollfd()` pattern.

Redis cron periodically refreshes cached memory statistics for `INFO memory`. On Linux, the RSS sample uses Redis’ existing `zmalloc_get_rss()` helper, which reads `/proc/self/stat` through `get_proc_stat_ll()`.

Run that slower memory-stat sample once per second instead of every 100ms. This keeps the existing Redis `run_with_period()` cron convention and avoids changing platform-specific file IO helpers.

Fixer observed this failure signal directly, but I did not independently reproduce it locally. The collected perf, strace, and `/proc` evidence showed a process mapped as `redis-check-rdb` but running as `redis-server`, sleeping in repeated `epoll_wait()` timeouts and then opening, reading, and closing `/proc/self/stat` about every 100ms.

The code-level cause is the normal server cron path: `serverCron()` calls `cronUpdateMemoryStats()`, which calls `zmalloc_get_rss()`. On Linux, `zmalloc_get_rss()` uses the local helper `get_proc_stat_ll()` to read `/proc/self/stat`. The `redis-check-rdb` name is expected to be an installed alias of the Redis server binary, so the relevant path is the server cron memory-stat path rather than the RDB checker parser.

The patch changes only the memory-stat cron cadence from `run_with_period(100)` to `run_with_period(1000)`. The expected effect is to reduce the observed `/proc/self/stat` sampling work by roughly 10x while keeping RSS and allocator statistics refreshed at a reasonable reporting cadence.

I followed the saved plan and did not change course. I checked `CONTRIBUTING.md`, `README.md`, and `tests/README.md`; no separate coding-style rule was relevant beyond using the existing Redis cron convention and local memory helpers.

No source change. The collected sample shows the postmaster sleeping in PostgreSQL’s latch/event-set wait path, not spinning in PostgreSQL code. A latch is PostgreSQL’s wakeup primitive for signals and process events; the observed `SIGUSR1`/`SIGURG` and `read()` activity matches that mechanism.

Fixer collected a possible runaway-process signal for `postgres`: kernel `read_tsc` samples, a backtrace through `epoll_wait()` and `WaitEventSetWait()`, and strace lines showing `SIGUSR1`, self `SIGURG`, a short `read()`, and return to `epoll_wait()`.

The cautious inference from the evidence is that this is normal postmaster latch wakeup behavior, not a confirmed PostgreSQL userspace loop. The process state was `S (sleeping)`, `wchan` was `do_epoll_wait`, and total CPU across 9 `postgres` processes was only about `0.6%`.

I made no source change. The saved plan said not to patch unless stronger evidence appeared; after rechecking `src/backend/postmaster/postmaster.c`, `src/backend/storage/ipc/waiteventset.c`, and `src/backend/storage/ipc/latch.c`, that remains the safest upstreamable outcome. I changed only the final confidence label from the saved plan’s `observed` to `inferred` because the current instruction classifies profiler/strace-only no-patch diagnoses as inferred.

The expected effect is to avoid sending an upstream patch that could perturb postmaster signal latency or connection handling without a demonstrated source bug.

Local conventions checked: `.github/CONTRIBUTING.md` points to PostgreSQL developer guidance, `README.md` points to upstream build docs, and the relevant subsystem already uses `pqsignal()`, `SetLatch()`, `ResetLatch()`, `WaitEventSetWait()`, `pg_memory_barrier()`, and `elog()/ereport()`.

`supervisord` tracks live managed child processes in `pidhistory`, a map from child PID to process object. When that map is empty, the main loop has no managed child to collect, so avoid the periodic `waitpid(-1)` sweep that otherwise reports “no children” from the kernel.

This keeps the existing one-second poll timeout, preserving signal, socket, and tick responsiveness. This also changes course from the earlier timeout-based plan because review showed that increasing the poll timeout could delay queued signal handling.

Fixer observed `/usr/bin/python3 /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf` with high CPU attribution in Python runtime frames. The concrete trace signal was repeated `wait4(-1, ..., WNOHANG) = -1 ECHILD` followed by `poll(..., 1000)`. This failure was observed by Fixer and not independently reproduced as high CPU locally.

The cautious code-level inference is that the relevant work is in supervisor’s application loop, not the Python runtime. `supervisord` already maintains `options.pidhistory` for live managed child PIDs, and uses the local `ServerOptions.waitpid()` wrapper for reaping. When `pidhistory` is empty, the periodic managed-child reap has nothing to collect, matching the no-child condition shown in the trace more closely than checking configured process groups.

The patch keeps the existing poll timeout and gates the main-loop `self.reap()` call on `self.options.pidhistory`. The test helper now counts `waitpid()` calls, and `test_supervisord` covers both a configured-but-idle process group with no tracked child PID and a tracked-child case that still reaps.

The expected effect is to reduce unnecessary idle `waitpid(ECHILD)` calls when there are no tracked managed child processes, without changing signal latency or normal reaping when child PIDs are present. A short source comment explains the `pidhistory` invariant.

`getpwnamallow()` checked whether a user existed for `Match Invalid-User` by calling `getpwnam(user)`, then immediately called `getpwnam(user)` again for the actual admission decision.

Reuse the first passwd lookup on the normal path and keep the second lookup only for the existing AIX `setauthdb` case, where the lookup is intentionally performed after switching authentication databases.

Fixer observed `sshd-session: gis [priv]` with perf samples in NSS/passwd-related code (`libnss_systemd.so.2` and `_nss_files_parse_pwent`) while `/proc` and strace showed the sampled process sleeping in `poll`/`restart_syscall`. This was observed by Fixer and not independently reproduced as a runaway CPU loop.

The cautious source-level cause is redundant NSS work in the server authentication admission path: `getpwnamallow()` performed two unconditional passwd database lookups for the same user on non-AIX systems. NSS is the Name Service Switch layer that resolves users/groups through files, systemd, LDAP, and similar backends.

The patch reuses the first `getpwnam(user)` result to set `ci->user_invalid` and to continue admission checks. It preserves the platform compatibility convention around `_AIX && HAVE_SETAUTHDB` by keeping the second lookup there. Existing OpenSSH helpers/conventions were followed: `pwcopy()` still owns the returned passwd data, existing logging style is unchanged, and no new file/process/allocation/locking APIs were introduced. No source comment was added because the control flow is direct.

The expected effect is to remove one unconditional NSS passwd lookup per user admission on the common path, reducing avoidable work in the same subsystem implicated by the collected perf evidence.

No source change is proposed. The collected perf, strace, and `/proc` evidence points to the postmaster waiting in PostgreSQL’s latch wait path, not to a proven userspace busy loop. A latch is PostgreSQL’s process wakeup primitive for signals and socket readiness.

The collected signal was a Fixer runaway-CPU investigation for `postgres`: a 3-second profile named `filemap_map_pages` as the hottest sampled kernel path, while the sampled postmaster showed `S (sleeping)`, `wchan` `do_epoll_wait`, and only `0.6%` total CPU across 9 postgres processes.

The cautious code-level inference is that the sampled postmaster was in normal event-loop sleep, not a confirmed PostgreSQL loop. The backtrace lands in `epoll_wait` via `WaitEventSetWait()` and `PostmasterMain()`, and the strace excerpt shows expected latch behavior: `SIGUSR1`, self-wakeup with `SIGURG`, draining a readiness fd with `read`, forking a child, then returning to `epoll_wait`.

I followed the saved plan and did not change course: no source diff was left because the evidence is indirect and the raw artifact files referenced by `evidence.json` are not present in this sandbox. I also checked upstream style context: there is no top-level `CONTRIBUTING` or `HACKING`; `README.md` points to PostgreSQL build docs. The relevant subsystem conventions are the existing latch/wait helpers `WaitEventSetWait`, `SetLatch`, `ResetLatch`, `WakeupMyProc`, `WakeupOtherProc`, `pg_memory_barrier`, and `ereport`/`elog`.

The expected effect is that no speculative change is sent upstream for a core signal/wakeup path where an incorrect patch could introduce missed wakeups or extra wakeups.

`channel_prepare_pollfd()` builds the `pollfd` array used by the SSH channel event loop. For a channel whose separate `sock` descriptor wanted read or write readiness, the code computed the correct poll event mask but stored zero in `pfd.events`, so `ppoll()` was not actually asked to watch that descriptor. Store the computed mask, matching the `rfd`, `wfd`, and `efd` paths.

Fixer observed an `sshd-session` process with profiler and trace evidence around the server poll path: the process was in `poll`/`restart_syscall`, with `/proc` showing `poll_schedule_timeout.constprop.0`. That failure was observed by Fixer and not independently reproduced.

The cautious code-level connection is that the channel poll setup could arm a channel socket internally while passing `events = 0` to `ppoll()`. In this subsystem, a `pollfd` entry is the descriptor plus the event bits that tell the kernel what readiness should wake the loop. A zero event mask can leave the event loop waiting without observing the readiness it just calculated.

The patch changes the separate `c->sock` branch in `channels.c` to assign `pfd[p].events = ev`. The expected effect is that channel socket readiness requested through `SSH_CHAN_IO_SOCK_R/W` is actually watched by `ppoll()`, avoiding a misarmed channel poll entry.

I followed the saved plan. I checked `README.md` and nearby channel/server loop code; the relevant local conventions are `channel_prepare_poll()`, `dump_channel_poll()`, `fatal_f()`, `xrecallocarray()`, and `ptimeout_*`. No new API or non-obvious state translation was introduced, so no source comment was needed.

No source change is proposed. The collected perf, strace, and `/proc` evidence points to normal postmaster latch wakeup handling rather than a proven PostgreSQL runaway loop.

The collected signal was a low CPU-hot profile for `postgres`: 0.6% aggregate CPU across 9 processes, a sampled postmaster in state `S (sleeping)`, kernel stack `do_epoll_wait`, and a userspace stack through `WaitEventSetWait()` and `PostmasterMain()`.

The cautious code-level inference is that this is PostgreSQL’s normal wait/latch path. In this subsystem, a latch is PostgreSQL’s cross-process wakeup primitive; `SetLatch(MyLatch)` wakes `WaitEventSetWait()`, and on Linux epoll builds that path uses `signalfd`/`SIGURG` and treats `EINTR` as retryable. The strace excerpt shows that sequence: `SIGUSR1`, self `SIGURG`, zero-timeout `epoll_wait`, signalfd `read`, process handling, then back to `epoll_wait`.

I made no source change, following the saved plan. A patch to `ServerLoop()` or `WaitEventSetWait()` from this evidence would be speculative and could regress signal responsiveness, connection accept handling, background-worker startup, or shutdown. The expected effect is that no unproven behavior change is introduced; this should instead be treated as a diagnosis requiring stronger evidence such as repeated immediate wakeups with no pending postmaster work.

Style/context checked: repository guidance available here was `README.md`; no `CONTRIBUTING` or `HACKING` file was present. Relevant local conventions/helpers are `WaitEventSetWait()`, `SetLatch()`/`ResetLatch()`, `ereport()`/`elog()`, `signal_child()`, and portability wrappers such as `closesocket()`.

No source change is included. The collected evidence points to an idle postmaster waiting in PostgreSQL’s wait-set/latch event loop, while the sampled `hash_search_with_hash_value` hotspot is a generic hash-table helper with no identified caller in the captured stack.

The likely root cause of the Fixer finding is an overclassification of normal postmaster wakeup activity, not a localized PostgreSQL defect. The evidence reports a 3-second perf sample where `hash_search_with_hash_value` accounted for 10.33%, but the sampled postmaster stack is blocked in `epoll_wait()` through `WaitEventSetWait()`, `/proc` reports state `S (sleeping)`, and total `postgres` CPU was only 0.6% across 9 processes.

At the code level, `WaitEventSetWait()` is PostgreSQL’s local wrapper for waiting on latches and sockets, and the postmaster uses it through `ServerLoop()` with `ResetLatch()`, `CreateWaitEventSet()`, and `AddWaitEventToSet()`. `hash_search_with_hash_value()` is the shared dynahash lookup helper used across many subsystems, and the evidence does not connect the sampled hotspot to a concrete postmaster caller or a tight loop.

I followed the saved plan and made no source change. A source patch here would be speculative and not pull-request-ready because it would either alter generic hash behavior or normal postmaster event-loop code without a reproduced or directly traced bug. The expected effect is no behavioral change; this result should be treated as an upstream bug-report diagnosis asking for a longer perf profile with call graphs, a live backtrace during actual sustained CPU, or a reproducible workload.

Contribution/style docs checked: `README.md` and `.github/CONTRIBUTING.md`. Relevant local conventions/helpers checked: `WaitEventSetWait()`, latch helpers such as `ResetLatch()`, postmaster signal handling via `pqsignal()`, PostgreSQL memory/logging conventions such as `palloc` and `elog`/`ereport`. No prior Fixer patch was present to replace.

`dockerd` subscribes to containerd task events through a channel pair: one channel carries event envelopes and one carries stream errors. The event loop now checks whether either channel has closed before using the received value. A closed event channel now triggers the existing containerd readiness wait and subscription restart path, while a closed error channel stops the loop cleanly. The event dispatch logic was split into a small helper so closed-channel behavior can be unit tested without a live containerd daemon.

Fixer observed `dockerd` in a sleeping state with many futex waits, an `epoll_pwait` hot path, and a strace sample dominated by futex waits with one epoll waiter. That failure signal was observed by Fixer and not independently reproduced; the raw artifact paths referenced by the evidence bundle were not present in the workspace, so the source connection is a targeted mitigation rather than a confirmed local reproducer.

The likely root cause is that `libcontainerd/remote.processEventStream` read from containerd subscription channels without checking the receive `ok` value. If the containerd event stream channel closes, Go returns the zero value immediately; the old loop could then treat that as another event instead of leaving or restarting the subscription. I changed the loop to handle closed channels explicitly, using the existing `c.logger` logging convention and existing `waitServe` restart helper. The expected effect is that a closed containerd task-event stream cannot keep `dockerd` churning through invalid event receives; it either restarts the subscription after containerd is ready or exits the stream loop cleanly.

I followed the saved plan. No relevant local wrappers for file IO, process spawning, allocation, locking, or platform compatibility were needed; the touched subsystem already uses `containerd/log`, `status.FromError`, and `waitServe`, so the patch stays with those conventions.

Fixer observed `sshd-auth` sleeping in an authentication failure path: the trace shows a `clock_nanosleep` before encrypted failure-response writes. Bound the scaled userauth failure delay so the total time since the request started cannot exceed `MAX_FAIL_DELAY_SECONDS`.

The delay still preserves the existing timing-obfuscation behavior, but the scale-up bucket is now capped before sleeping.

Fixer observed this failure signal directly but I did not independently reproduce it: `sshd-auth: root [net]` was in `S (sleeping)`, with strace showing a 1.612s `clock_nanosleep` followed by writes, and perf/proc evidence classifying the sample as timer-heavy.

The matching code path is `auth2.c` user authentication failure handling. `ensure_minimum_time_since()` applies a per-user delay before `SSH2_MSG_USERAUTH_FAILURE`; if authentication work has already passed the requested delay, it doubles the target delay bucket. Before this patch, that doubled bucket was not capped, so the total failure handling time could exceed the function’s own `MAX_FAIL_DELAY_SECONDS`.

The patch clamps the scaled bucket to `MAX_FAIL_DELAY_SECONDS` and avoids a zero or negative sleep. The expected effect is that authentication failure timing remains padded, but `sshd-auth` cannot add an oversized sleep past the intended maximum while preparing a failure response. I kept the short source comment explaining the cap invariant.

Review round 1 found generated regression byproducts in the workspace. I removed those unintended files; the final patch contains only `auth2.c`.

Local conventions checked: `README.md` and `regress/README.regress`; nearby code uses `monotime_double()`, `debug3_f()`, `nanosleep()`, `ssh_packet_write_wait()`, `atomicio()`, `xmalloc()`, and `freezero()`. No relevant local wrapper replaces this direct sleep path.

`waitForIfUpped` subscribes to Linux netlink link updates while waiting for an interface to become up. Netlink is the kernel socket API used here for network-interface events.

When the function exits, it closes the subscription and drains the update channel. That drain had a three-second timeout, but after logging the timeout it kept looping, so a subscription that failed to close its channel could keep the caller blocked indefinitely. Return after the timeout warning so the timeout is actually bounded.

Fixer observed `dockerd` with a perf hotspot in kernel `__futex_hash`, many threads waiting in futex syscalls, and unsymbolized dockerd frames. I did not independently reproduce that live failure. After adjusting the sampled PCs for the PIE load base from the evidence maps, `go tool addr2line /usr/sbin/dockerd` resolved representative frames to `github.com/vishvananda/netlink.linkSubscribeAt.func2`, which is reached from Docker through `libnetwork/osl.waitForIfUpped()` and the local `internal/nlwrap.LinkSubscribeWithOptions` helper.

The cautious code-level cause is that `waitForIfUpped()` intended to bound cleanup of a netlink `LinkSubscribe` watcher, but its timeout case only logged and then continued waiting. If the netlink package did not close the update channel, that cleanup path could remain stuck while subscription goroutines remained around.

The change adds a `return` after the existing timeout warning. The expected effect is that this cleanup path stops waiting after its documented timeout instead of adding another stuck waiter around an already-failed netlink subscription. This follows existing local patterns: it keeps `nlwrap.LinkSubscribeWithOptions`, `github.com/containerd/log`, and the existing timeout-based control flow; no new helper or platform API was introduced. I changed course from the saved no-patch plan because local symbolization tied the observed frames to this specific netlink subscription path.

No source change is proposed. The collected profile shows `sshd-session` sleeping in `poll`, not a proven OpenSSH busy loop. The review finding was addressed by removing unintended generated-file drift, so the no-patch response now matches the workspace.

Fixer collected a 3-second profile for `sshd-session: gis [priv]` with low aggregate CPU, one `restart_syscall(<... resuming interrupted poll ...>)`, `/proc` state `S (sleeping)`, and wait channel `poll_schedule_timeout`. Hot samples were split across kernel code, `pam_set_item`, libc, and `libnss-systemd`; the OpenSSH frames were stripped, and the raw investigation directory was unavailable.

The cautious code-level inference remains that the sampled process was blocked in an event wait, not demonstrably spinning in OpenSSH. The relevant OpenSSH paths already use local conventions: `serverloop.c` uses `ptimeout_*` from `misc.c` for `ppoll` deadlines, and `monitor.c` waits in `poll` for monitor/log fd activity.

I made no source change. I did remove the unintended regenerated `aclocal.m4`, `config.h.in`, and `configure` changes left by validation, addressing the review’s metadata-drift finding. The expected effect is that no speculative OpenSSH behavior change is proposed without stronger observed or reproduced evidence.

No source change. The collected signal points at the postmaster’s normal wait path rather than a demonstrated busy loop. A `WaitEventSet` is PostgreSQL’s wrapper for waiting on latches and sockets; the sampled stack is in that wrapper’s `epoll_wait()` backend while `/proc` reports the process sleeping.

Fixer collected a short profiler/backtrace sample for `postgres` showing `PostmasterMain()` -> `WaitEventSetWait()` -> `epoll_wait()`, with one kernel hotspot under `set_pte_range`. The same bundle reports the sampled postmaster as `S (sleeping)`, `wchan` as `do_epoll_wait`, total CPU around `1.0%`, and only one captured `epoll_wait` syscall over the strace window.

The cautious source-level inference is that this is the normal postmaster idle loop in `src/backend/postmaster/postmaster.c`, not enough evidence for a PostgreSQL upstream bug. The relevant local conventions are `WaitEventSetWait()`, `AddWaitEventToSet()`, `ResetLatch()`, `SetLatch()`, `TimestampDifferenceMilliseconds()`, and PostgreSQL logging wrappers such as `ereport()`/`elog()`. `src/include/storage/latch.h` explicitly describes this latch/wait pattern and warns that timeouts should be avoided when possible.

I followed the plan and changed course only by classifying the result as `inferred`: the planned independent `initdb`/postmaster/`strace` check was blocked by sandbox privilege restrictions, so there is still no stronger signal showing rapid zero-timeout `epoll_wait()` returns. No source diff is left because a delay or wait-loop change here would be speculative and could slow connection acceptance, background worker startup, shutdown handling, or crash recovery.

The expected effect of this no-patch result is to avoid submitting a misleading upstream patch until a trace shows the postmaster actually spinning instead of blocking normally.

No source change is proposed. The collected signal points at an idle PostgreSQL postmaster blocked in its normal wait set, not at a proven busy-poll defect in PostgreSQL.

Fixer reported a runaway-process finding for `postgres`, with a backtrace through `WaitEventSetWait()` to `epoll_wait()`. The same evidence also shows `process_state: S (sleeping)`, `wchan: do_epoll_wait`, total CPU around 0.6%, and only one `epoll_wait` line captured over a five-second strace window.

The cautious code-level inference is that the postmaster was in `ServerLoop()` waiting on PostgreSQL’s `WaitEventSet` abstraction, which is the normal latch/socket wait mechanism for accepting connections and handling postmaster signals. I inspected the relevant code in `src/backend/postmaster/postmaster.c` and `src/backend/storage/ipc/waiteventset.c`; it already uses the local helpers `CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, and `ResetLatch()`, rather than raw ad hoc polling.

I followed the saved plan and did not change course: without evidence of repeated immediate wakeups, adding sleeps or changing the event loop would be speculative and could delay connection handling, reload/shutdown processing, or child-exit handling. The expected effect of this no-patch outcome is to avoid landing a PostgreSQL source change for what appears to be a classifier false positive or insufficient performance evidence.

PostgreSQL style guidance checked: `doc/src/sgml/sources.sgml` documents BSD-style formatting, 4-column tabs, pgindent-compatible layout, and `ereport()`/`elog()` for server messages.

No source change. The collected trace shows the postmaster in PostgreSQL’s normal wait path: a wait event set, PostgreSQL’s abstraction over `epoll` plus latch wakeups, was sleeping until a signal set the postmaster latch. The available evidence does not identify an upstream PostgreSQL bug.

Fixer collected a perf/strace signal for `postgres` with a backtrace through `epoll_wait()` and `WaitEventSetWait()`, plus kernel hot symbols such as `clear_page_erms`. The same evidence reports the process state as sleeping, wait channel `do_epoll_wait`, and only `0.6%` total CPU across 9 PostgreSQL processes.

The cautious inference from the code and evidence is that this is the normal postmaster wait loop, not a demonstrated runaway loop. The strace sequence shows `SIGUSR1`, `SetLatch()` wakeup through `SIGURG`, a zero-timeout `epoll_wait()` returning the latch event, a self-pipe/signalfd `read()`, and then `clone()` for child startup. Nearby code already uses the local helpers and conventions: `ConfigurePostmasterWaitSet()`, `WaitEventSetWait()`, `SetLatch()`, and `ResetLatch()`.

I followed the saved plan and made no source change because the evidence remains indirect and does not support a pull-request-ready patch. The expected effect of this no-patch result is to avoid perturbing postmaster signal and connection handling based on a profile sample that matches intended control flow.

`libcontainerd/remote` subscribes to containerd task events and forwards them into dockerd. If containerd closes the event channel without an error, the old receive ignored the channel `ok` result and could keep reading zero-value events forever. Treat a closed event stream as a broken subscription, wait for containerd to be ready, and restart event processing.

Fixer observed `dockerd` with profiler, strace, and `/proc` evidence showing a sleeping daemon with many futex waits and socket/IPC churn while running with `--containerd=/run/containerd/containerd.sock`. That means dockerd was using an external containerd client, not the managed containerd supervisor path. The failure was observed by Fixer and not independently reproduced from a live daemon.

The code-level issue is in `libcontainerd/remote.processEventStream`: a closed Go channel can still be received from, yielding the zero value repeatedly. The previous loop read from `eventStream` without checking `ok`, so a closed containerd event stream could be handled as repeated invalid empty events instead of reconnecting.

I changed the receive to check `ok`. When the stream closes during shutdown, it exits cleanly; otherwise it logs the closed stream, waits for containerd readiness using the existing `waitServe` helper, and restarts the subscription. I followed the existing local conventions: `containerd/log` via `c.logger`, context cancellation, and the existing containerd event subscription API. No relevant local wrapper replaces channel receive logic; process helpers such as `pkg/process` and `pkg/pidfile` were not relevant to this path. I added a short source comment explaining the closed-channel invariant.

The expected effect is that dockerd no longer spins on zero-value task events after a containerd event channel closes unexpectedly, reducing one plausible event-stream source of the observed churn.

Keep containerd task event stream recovery inside one goroutine and handle closed event channels explicitly. If the stream drops, dockerd now cancels the old subscription, waits for containerd to report ready, and delays briefly before resubscribing instead of starting a replacement goroutine immediately.

Refinement round 1 addresses the review finding by rewording the source comment and patch explanation to describe reconnect goroutine churn, not accumulated event processors.

Fixer observed `dockerd` with 185 threads, mostly blocked in futex waits, with strace showing repeated `futex`, `nanosleep`, `epoll_pwait`, `waitid`, and some nonblocking socket reads. This was observed by Fixer and not independently reproduced.

The cautious code-level connection is the libcontainerd task event stream, which is the daemon’s long-lived containerd event subscription for task lifecycle messages. Its recovery path spawned a replacement `processEventStream` goroutine on recoverable stream errors and did not distinguish closed event/error channels from real events.

This patch keeps reconnect handling in the existing goroutine, explicitly treats closed channels as a reconnect condition, preserves the existing `waitServe` readiness check, and adds a short timer before resubscribing. It follows the local `containerd/log`, `context.WithCancel`, and timer conventions already used in this subsystem. I added a short comment documenting that reconnects stay in one goroutine to avoid replacement-goroutine churn.

The expected effect is to reduce event-stream reconnect churn when the containerd event subscription repeatedly fails or closes.

On platforms without `openlog_r()`, keep the libc syslog connection open between daemon log messages instead of closing it after every write. OpenSSH still calls `openlog()` before each `syslog()` write so its program name and facility are restored if another library touched the process-global syslog state.

Fixer observed `sshd-session` in a low-CPU sampled state with `/proc` showing it sleeping in `poll`, while strace showed pre-authentication invalid-user logging repeatedly opening a Unix datagram socket, connecting to `/dev/log`, sending syslog messages, and closing the socket. This failure was observed by Fixer and not independently reproduced.

The code-level cause is that the non-`openlog_r()` path in `log.c` called `openlog()`, `syslog()`, and `closelog()` for every daemon log message. I changed only that fallback path: `log_init()` still closes and reopens syslog when OpenSSH’s logging identity changes, and `do_log()` still calls `openlog()` before each write to preserve OpenSSH’s ident/facility after PAM, libwrap, or another library uses process-global syslog state, but it no longer calls `closelog()` after every message.

The expected effect is to reduce `/dev/log` socket close/reopen churn during bursts of monitor logging while preserving the existing protection against external-library syslog state changes. This refinement addresses both review findings: the code now refreshes OpenSSH’s syslog identity before each write, and the stale “open/close” comment was corrected. I used the existing OpenSSH logging helpers and monitor logging convention (`log_init()`, `do_log()`, `sshlogdirect()`, `mm_log_handler()` / `monitor_read_log()`), and added a short comment for the process-global syslog invariant.

No source change is proposed. The collected `sshd-auth` signal looks like normal disconnect handling after an authentication delay, not a demonstrated busy-poll loop: the process was sleeping, used at most 0.4% CPU, blocked in `read`, saw one `ppoll`, then exited after `ECONNRESET`.

Fixer collected a short perf/strace sample for `sshd-auth` labelled as a likely busy-poll loop. The concrete trace shows `clock_nanosleep`, a disconnect packet write, one `ppoll` returning `POLLIN|POLLERR|POLLHUP`, `read(...)=ECONNRESET`, a monitor log write, and `exit_group(255)`. `/proc` evidence showed the process in sleeping state with `wchan` at `unix_stream_read_generic`, not running in a tight userspace loop.

The cautious code-level inference is that this maps to existing OpenSSH auth and packet paths: `auth2.c` deliberately sleeps to enforce authentication failure timing, while `packet.c` uses `ppoll`, `read`, `ssh_packet_*`, `sshbuf`, and `logdie`/`fatal` paths to report and exit on connection reset. I did not find a confirmed source defect to patch.

I followed the saved plan and left no source diff. A source patch would be speculative without stronger evidence, especially in OpenSSH authentication and packet handling. The expected effect of this report is to avoid landing an unproven behavior change and to give upstream a precise diagnosis plus validation blockers.

Local conventions checked: only `README.md` was present among contribution/style docs; nearby code uses OpenSSH’s `ssh_packet_*`, `sshbuf`, `atomicio`, `x*alloc`, `freezero`, `logdie`/`fatal`, and `ppoll` timeout helper conventions.

No source change is proposed. The likely root cause is an over-classified profiler signal: the collected perf, strace, and `/proc` excerpts show `sshd-session` sleeping in `poll(2)`, not spinning in OpenSSH code.

Review round 1 found validation artifacts left in `regress/`. I removed those unintended files so the worktree again matches `Git Add Paths: None`.

The collected signal was a Fixer runaway-process report for `sshd-session`, with perf samples including kernel `clear_page_erms`. The same evidence reports only `0.1%` total CPU across four `sshd-session` processes, process state `S (sleeping)`, `wchan=poll_schedule_timeout.constprop.0`, and a strace excerpt showing a single `restart_syscall(<... resuming interrupted poll ...>)`.

The cautious code-level inference is that the sampled process was in the normal SSH server session loop: `server_loop2()` prepares channel file descriptors, `wait_until_can_do_something()` computes deadlines with `ptimeout_*`, and then blocks in `ppoll()`. That is an idle wait path, not enough evidence for an upstream OpenSSH source patch.

I made no source change. The only refinement was removing unintended regression artifacts called out by review. The expected effect is to avoid shipping speculative OpenSSH behavior changes and keep the proposal clean until stronger evidence exists.

No source change. The collected profile does not identify an OpenSSH bug strongly enough for an upstream patch: `sshd-session` was sampled as CPU-hot, but `/proc`, `strace`, and the backtrace show it sleeping in `poll`/`restart_syscall`, with the hot symbol attributed to kernel `netlink_create`.

Fixer collected a profiler signal for `sshd-session: gis [priv]`: 100% of sampled hot-path CPU was attributed to kernel `netlink_create`, while the sampled thread state was `S (sleeping)`, `wchan` was `poll_schedule_timeout.constprop.0`, and `strace` captured only `restart_syscall(<... resuming interrupted poll ...>)`.

The cautious inference is that this is not currently tied to an OpenSSH userspace loop. The mapped libraries include PAM/systemd/NSS components, and the inspected OpenSSH session paths use normal blocking `poll`/`ppoll` waits. I followed the saved plan and did not make a speculative source change.

No code was changed. A useful upstream bug report should include symbolized userspace frames and a short perf/strace sample from a live session that ties the netlink activity to a specific caller.

The expected effect is no behavioral change; this avoids submitting an inferred, non-pull-request-ready patch.

`sshd-session` was observed in the server event loop around `poll`/`restart_syscall`. In the channel poll setup code, `io_want` records which operations a channel wants to poll for, and `pollfd.events` is the mask passed to `poll`/`ppoll`.

The `c->sock` path computed the requested socket events in `ev`, but then stored zero in `pfd[p].events`. Store `ev` instead, matching the `rfd`, `wfd`, and `efd` paths, so socket-only channel readiness is actually armed.

Fixer observed an `sshd-session` process with backtraces in `poll`, a single `restart_syscall` strace sample, `/proc` state `S (sleeping)`, and an `event-loop-wakeups` signal. I did not independently reproduce the runtime failure.

The likely root cause is that `channel_prepare_pollfd()` could build a pollfd entry for a channel socket while subscribing to no events. That means the server loop may sleep in `ppoll` without being woken for socket readiness that the channel layer already requested.

The change makes the socket pollfd use the computed `ev` mask instead of zero. The expected effect is that `sshd-session` will correctly wake for readable or writable channel sockets, avoiding a missed event-loop wakeup in this path.

I followed the existing local channel poll conventions: `io_want`/`io_ready`, `dump_channel_poll()`, `fatal_f()`, `xrecallocarray()`, and `ptimeout_*` handling. The only matching contribution/style document found was `README.md`; no new helper or platform API was introduced.

No source change is included. The collected signal matches PostgreSQL’s normal postmaster wait path more than a proven busy loop, so an upstream patch would be speculative.

I followed the saved plan. The code inspection did not prove it wrong.

The collected signal was a profiler/trace report for `postgres` showing `PostmasterMain()` leading to `WaitEventSetWait()` and then `epoll_wait()`. The `/proc` excerpts say the sampled process was sleeping, `wchan` was `do_epoll_wait`, strace captured only one unfinished `epoll_wait(8` over the trace window, and the whole target reported about `0.6%` CPU across 9 processes.

The likely root cause is a false-positive busy-poll classification, or at least insufficient evidence for a PostgreSQL source bug. In PostgreSQL, a wait event set is the local wrapper that waits on latches and sockets together; the postmaster uses `CreateWaitEventSet`, `AddWaitEventToSet`, `WaitEventSetWait`, and `ResetLatch` in `ServerLoop()`. The latch documentation describes this as the intended way to sleep without polling. There is an intentional nonblocking path while background workers are pending, but the available evidence shows the sampled process sleeping in the kernel wait, not repeatedly returning from it.

I made no code change. The raw artifact paths named in the evidence bundle were not present in this workspace, so I could not inspect fuller strace/perf logs beyond the JSON excerpts. The expected effect is to avoid landing an upstream patch based on indirect evidence that does not demonstrate a PostgreSQL defect; a stronger report should include a trace showing repeated immediate `epoll_wait()` returns or a reproducible workload.

Style/helper check: top-level `README.md` points to PostgreSQL build docs, and no `CONTRIBUTING`/`HACKING` file was present. The relevant local helper convention is the existing `WaitEventSet`/`Latch` API in `src/include/storage/latch.h` and `src/include/storage/waiteventset.h`.

Failed user authentication applies a small per-user delay to reduce timing leaks. When authentication work already exceeded that delay, `ensure_minimum_time_since()` scaled the delay upward until it exceeded the elapsed time, then slept the difference. Slow monitor or authentication backend work could therefore turn a millisecond-scale delay into a much longer `nanosleep()`.

Keep a bounded per-user delay for slow failed authentications instead of scaling it to match the elapsed backend time. Fast failures still wait until the requested per-user delay has elapsed.

Fixer observed `sshd-auth` sleeping with traces dominated by `read`, `read`, and `clock_nanosleep`; sampled backtraces included `clock_nanosleep()`/`nanosleep()`, and the strace excerpt showed sleeps of about 0.46s and 1.78s after monitor/socket reads. This failure was observed by Fixer and not independently reproduced.

The source-level connection is a cautious match from inspection: `auth2.c` computes a per-user failed-auth delay, and the old slow-auth path repeatedly doubled that delay until it exceeded elapsed authentication work before calling `nanosleep()`. I changed that path to keep one bounded per-user delay when elapsed time already exceeds the target, rather than scaling the delay up to the slow backend time. I also added a short comment because this timing tradeoff is non-obvious.

The expected effect is to reduce long post-authentication sleeps in `sshd-auth` while preserving a per-user delay for failed authentication attempts instead of returning immediately after slow backend work.

This refinement addresses the review findings by replacing the first pass’s early return with a bounded delay and by describing the `auth2.c` mapping as an inspection-based connection, not a locally reproduced root cause. I found only `README.md` among the requested style docs, no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The patch uses existing OpenSSH conventions in this file: `monotime_double()`, `debug3_f()`, and portable `nanosleep()` support.

No source change is included. The collected signal is an indirect runtime trace from installed rsync 3.4.1, and the 3.4.2 source tree already contains related keep-alive handling for this area. A source patch would be speculative without reproducing the behavior against this tree.

Fixer collected a perf/strace signal where rsync repeatedly returned from `pselect6` and read short 8-byte packets while the process was sleeping in `poll_schedule_timeout`. Those packets decode like rsync multiplexed-I/O `MSG_DATA` keep-alive packets, where multiplexed I/O is rsync’s control-message stream interleaved with file data.

The cautious code-level inference is that the trace is tied to timeout keep-alive behavior in `io.c`, especially `maybe_send_keepalive()`, `send_msg(MSG_DATA, "", 0, 0)`, `set_io_timeout()`, and `perform_io()`. The evidence was collected from installed `3.4.1+ds1-7`, while this workspace is `3.4.2+ds1-2`; `NEWS.md` already notes a 3.4.2 fix for too-aggressive keep-alive messages early in a transfer.

I made no source change. This follows the saved plan instead of adding a speculative throttle that could break legitimate `--timeout` liveness handling between sender, receiver, and generator processes. The expected effect is no behavior change from this proposal; the useful upstream report is that any further patch needs a reproduction or trace against 3.4.2.

Style/helper scan: only `README.md` and `doc/` were present from the requested contribution-doc list. The relevant local helpers are rsync’s existing `send_msg()`, `io_flush()`, `set_io_timeout()`, `rprintf()`, and `rsyserr()` conventions. No prior Fixer patch was found in `debian/patches`.

No source change is proposed. The collected `sshd-session` evidence points to a process blocked in `poll()`, not to an OpenSSH userspace busy loop. Changing `serverloop.c` or channel polling from this signal alone would be speculative.

The collected signal says `sshd-session: gis [priv]` was a runaway-process candidate, but the same bundle shows `State: S (sleeping)`, wait channel `poll_schedule_timeout`, a single `restart_syscall` resuming `poll`, and only `0.1%` total CPU across sampled `sshd-session` processes. The hottest samples were in kernel/libc symbols such as `inet6_dump_addr`, while the OpenSSH frames were unresolved.

The likely root cause is a profiler classification mismatch or incomplete symbolization, not a demonstrated OpenSSH loop. I inspected the session event loop and channel polling paths; the relevant local conventions are `ptimeout_*` timeout helpers, `monotime()`, `ssh_signal()`, `fatal_f`/`error_f` logging, and `xmalloc` allocation wrappers. `README.md` documents the normal build flow; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` guidance was present.

Following the saved plan, I made no source changes. The expected effect is to avoid landing an upstream-unready patch until a symbolized trace or reproducible busy loop connects the observed signal to specific OpenSSH code.

No source change. The collected evidence is a mixed, short profiler sample: the captured postmaster is sleeping in `epoll_wait`, while another hot symbol points at serializable transaction cleanup. That is not enough to justify changing PostgreSQL’s wait loop or predicate-lock code.

Fixer observed a `postgres` process group with low CPU usage (`max_cpu_percent: 0.6`) and a three-second profile split between kernel `generic_permission` and PostgreSQL `ReleasePredicateLocks`. The `/proc` evidence says the sampled process was sleeping (`S`) with `wchan` `do_epoll_wait`, and the backtrace is in `WaitEventSetWait()`, PostgreSQL’s latch/event waiting abstraction.

The cautious inference is that the report mixed normal postmaster event-loop wakeups, periodic `postmaster.pid` recheck I/O, and possibly backend serializable transaction cleanup. `ReleasePredicateLocks()` is backend transaction cleanup, while the representative stack is the postmaster sleeping in `ServerLoop()`, so the evidence does not identify one source-level loop.

I followed the saved plan and did not leave a source diff. Nearby code already uses PostgreSQL helpers and conventions: `CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, `ResetLatch()`, `RecheckDataDirLockFile()`, `pgstat_report_wait_start/end`, `LWLock`, `dlist_foreach_modify`, and predicate-lock cleanup helpers such as `ReleaseOneSerializableXact()`. `.github/CONTRIBUTING.md` points to PostgreSQL developer docs; no local HACKING file was present.

The expected effect is to avoid an upstream-hostile speculative patch. A useful upstream report should include per-PID samples/backtraces proving whether the active CPU path is the postmaster wait loop or a backend in `ReleasePredicateLocks()`.

`transitive_dependencies()` used a mutable default `set`, so independent dependency walks could share package names from previous calls. Use a fresh set for each top-level walk and add a unit test to keep package-marking dependency state isolated.

Fixer observed `/usr/bin/unattended-upgrade` consuming CPU, with perf/backtrace samples in `apt_pkg`/`libapt-pkg` resolving APT index files and `strace` showing repeated `newfstatat()` probes, including missing APT list files. This failure was observed by Fixer and not independently reproduced as the full high-CPU/newfstatat loop.

The relevant script-side code repeatedly asks APT about package candidates while marking upgrades. In that path, `transitive_dependencies()` used `acc=set()` as a default argument; in Python that set is created once and reused, so dependency names from one package can leak into later dependency walks. That can make later package-marking passes inspect and adjust unrelated stale dependencies, increasing calls into APT metadata lookup.

The patch changes `transitive_dependencies()` to create a fresh accumulator when no caller supplies one, while preserving the explicit accumulator used by recursion. I followed the project’s `HACKING.md` test convention and the existing package-marking helpers; no relevant local file/process/platform wrapper was needed for this pure-Python state fix.

The expected effect is to prevent unrelated dependency walks from accumulating stale package names and reduce unnecessary APT candidate/index lookups during unattended-upgrades package marking.

Likely root cause: the collected perf, strace, and `/proc` evidence describes an idle postmaster blocked in the normal PostgreSQL wait-event path, not a confirmed busy loop. I made no source change because the evidence is indirect and contradicted by the process state, low CPU sample, and single unfinished `epoll_wait()` trace.

Fixer collected a `postgres` stack in `PostmasterMain()` -> `WaitEventSetWait()` -> `epoll_wait()`, with a busy-poll classification, but the same bundle shows `State: S (sleeping)`, `wchan: do_epoll_wait`, total sampled CPU around 0.7%, and only one `epoll_wait` syscall line over the strace window.

The cautious code-level inference is that the postmaster was in its normal idle wait. The postmaster loop uses PostgreSQL’s local wait helpers: `ConfigurePostmasterWaitSet()`, `WaitEventSetWait()`, and `ResetLatch()`. The Linux implementation uses the project’s `WaitEventSet` abstraction over `epoll`/`signalfd`, which is the existing subsystem convention found in nearby code. `README.md` and `.github/CONTRIBUTING.md` point to upstream PostgreSQL contribution guidance; no additional local helper was needed because no new API was introduced.

I followed the saved plan and did not change course: no source patch was left because there was not enough direct or reproduced evidence to make an upstream-ready behavior change. The expected effect is no runtime behavior change; this avoids patching a central wait primitive based on an indirect profiler label.

No source change is proposed. The collected signal points to the postmaster, PostgreSQL’s parent server process, sleeping in the normal wait-set path rather than spinning in a confirmed busy loop.

The relevant subsystem already uses PostgreSQL’s `WaitEventSet` and latch helpers (`CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, `ResetLatch()`), and the inspected code path intentionally blocks in `epoll_wait()` while waiting for latch or socket events.

Fixer reported a likely busy-poll loop because a sampled `postgres` process had a backtrace through `WaitEventSetWait()` and `epoll_wait()`, with kernel samples including `__lruvec_stat_mod_folio`. The same evidence shows the process state as `S (sleeping)`, `wchan` as `do_epoll_wait`, only one captured `epoll_wait` syscall over the strace window, and total CPU around 0.7% across nine postgres processes.

At the code level, `PostmasterMain()` reaches `ServerLoop()`, which waits through PostgreSQL’s `WaitEventSet` abstraction. On Linux that abstraction uses `epoll_wait()` as its blocking readiness primitive. A postmaster stack stopped there is expected when the server is idle; it is not enough evidence of repeated immediate wakeups.

I followed the saved plan and did not leave a source diff. A source patch here would be speculative unless stronger evidence shows repeated immediate `epoll_wait()` returns, repeated latch/socket wakeups, or measurable CPU consumption attributable to this loop. The expected effect is no behavior change; this is a no-patch diagnosis suitable for an upstream bug report or for collecting a more targeted trace.

Redis samples resident set size (RSS, the process memory resident in RAM) from `serverCron()` every 100 ms. On Linux that goes through `get_proc_stat_ll()`, which reopened `/proc/self/stat` for every sample.

Keep a cached `/proc/self/stat` descriptor and read it with `pread()`. Track the pid that opened the descriptor so forked children reopen it for their own `/proc/self/stat`. This keeps the existing sampling cadence and parsing logic, but avoids repeated open/close work in the idle cron path.

Fixer observed a Redis process with repeated `epoll_wait`, `openat`, and `read` activity, where the proc evidence showed periodic reads of `/proc/self/stat`. This was observed by Fixer and not independently reproduced locally because ptrace-based tracing is blocked in this sandbox.

The cautious code-level cause is Redis’ Linux RSS sampling path: `serverCron()` calls `cronUpdateMemoryStats()` under the existing `run_with_period(100)` convention, and `zmalloc_get_rss()` reads field 24 through `get_proc_stat_ll()`. Before this patch, every sample opened, read, and closed `/proc/self/stat`.

The change keeps the existing helper and return contract, uses Redis’ existing direct Linux procfs style with `O_CLOEXEC`, and adds a short comment for the fork invariant: the cached descriptor must be reopened if `getpid()` changes. No relevant local procfs file-IO wrapper was found; `anetCloexec()` exists for networking fds, but this block already uses direct libc procfs APIs.

The expected effect is to reduce repeated procfs open/close churn during idle memory sampling while preserving the same RSS value parsing and cron frequency.

No source change is included. The collected trace shows the postmaster blocked in PostgreSQL’s normal wait-event path, not a demonstrated busy loop, so an upstream patch would be speculative.

The collected signal was a Fixer runaway-process report for `postgres`, with perf samples mentioning `get_mem_cgroup_from_mm` and a backtrace through `WaitEventSetWait()` into `epoll_wait()`. The `/proc` evidence says the sampled postmaster was in state `S (sleeping)`, `wchan` was `do_epoll_wait`, CPU was low (`max_cpu_percent` 0.6), and `strace` captured one unfinished `epoll_wait` over five seconds.

The likely root cause is a classification mismatch: a normal PostgreSQL postmaster wait was labeled as a busy-poll loop. A `WaitEventSet` is PostgreSQL’s latch/socket waiting abstraction; `ServerLoop()` uses `CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, and `ResetLatch()` to sleep for latch notifications or connection readiness. The evidence does not show repeated completed zero-timeout waits or sustained CPU in PostgreSQL code.

I followed the saved plan’s no-patch direction, but changed the final confidence from `observed` to `inferred` because the evidence supports a diagnosis of the report, not a pull-request-ready source defect. I checked `.github/CONTRIBUTING.md`, `README.md`, and `doc/src/sgml/sources.sgml`; the relevant local conventions are PostgreSQL BSD style, `ereport`/`elog` for server diagnostics, and the existing latch/wait-event helpers. No relevant local helper was missing.

The specific change made is none. The expected effect is to avoid landing a speculative patch that could add latency or disturb PostgreSQL’s established latch semantics without evidence of an actual source bug.

No commit is proposed. The collected perf, strace, and `/proc` evidence does not identify a PostgreSQL source bug strongly enough for an upstream patch: the sampled postmaster was sleeping in `epoll_wait`, total CPU was below 1%, and the observed `postmaster.pid` read matches PostgreSQL’s normal periodic data-directory lockfile recheck.

Fixer collected a short profile and trace for `/usr/lib/postgresql/18/bin/postgres` that was classified as a possible runaway process. The concrete signal was weak: the process state was `S (sleeping)`, `wchan` was `do_epoll_wait`, total CPU was `0.7%`, max per-process CPU was `0.6%`, and the three-second profile split samples between kernel `free_pcppages_bulk` and PostgreSQL `pgstat_report_wal`.

The likely root cause is an overclassified idle/postmaster wakeup sample, not a demonstrated userspace loop. The backtrace is the normal postmaster wait path through `WaitEventSetWait()`. The strace excerpt’s `postmaster.pid` open/read maps to `RecheckDataDirLockFile()`, PostgreSQL’s once-per-minute safety check that the data-directory lock file has not been removed or replaced. The `pgstat_report_wal()` path also already uses local pgstat flush helpers, and nearby helpers such as `pgstat_flush_backend()` and `pgstat_io_flush_cb()` avoid locking when there is no pending backend WAL or I/O data.

I followed the saved plan and made no source change. A patch here would be speculative: it could change WAL/statistics behavior without proving any connection to the collected signal. The expected effect is no behavior change and no upstream patch based only on an ambiguous profiler sample.

Local conventions inspected: `WaitEventSetWait()`/latch wakeups for postmaster waiting, `RecheckDataDirLockFile()` for lockfile validation, `pgstat_*_flush_cb()` helpers, and `LWLockConditionalAcquire()` for non-forced statistics flushing.

No source change is proposed. The collected perf, strace, and `/proc` evidence most likely sampled a normally idle postmaster waiting in `epoll_wait()`: the process state was `S (sleeping)`, `wchan` was `do_epoll_wait`, CPU was low, and the strace excerpt contained only one unfinished `epoll_wait` call over 5 seconds.

The collected signal was a Fixer runaway-process report for `postgres`, with a backtrace through `WaitEventSetWait()` into `epoll_wait()` and a profiler hot symbol in the kernel. The code-level inference is cautious: PostgreSQL’s postmaster normally sleeps in `ServerLoop()` through the local wait-event abstraction, specifically `ConfigurePostmasterWaitSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, `ResetLatch()`, and `DetermineSleepTime()`.

I did not make a source change because the available evidence does not show repeated immediate `epoll_wait()` returns or a confirmed zero-timeout loop. The raw investigation files referenced by `evidence.json` were also absent, so the embedded excerpts are the only evidence available. The expected effect of leaving no diff is to avoid an upstream patch that could accidentally delay connection accept, shutdown, reload, or background-worker handling without a proven bug.

I followed the saved plan and did not change course. I also checked the contribution/style entry points: `README.md` points to upstream build docs, `.github/CONTRIBUTING.md` points to the PostgreSQL developer site, and the relevant subsystem already has PostgreSQL-specific wait/latch helpers that should be used for any future patch.

No source change was made. The collected signal points at the postmaster blocked in PostgreSQL’s normal wait-event path, not at a confirmed busy loop. The postmaster uses `WaitEventSetWait()` around `epoll_wait()` and is expected to sleep there while idle; the evidence also reports `S (sleeping)`, `wchan=do_epoll_wait`, only one unfinished `strace` line, and low CPU usage.

Fixer collected a perf/backtrace sample with the postmaster in `WaitEventSetWait()` above `epoll_wait()` and classified it as a likely busy poll. The `/proc` and `strace` excerpts are more consistent with an idle postmaster blocked in the kernel: process state was sleeping, `wchan` was `do_epoll_wait`, CPU was below 1%, and the `strace` excerpt contains only `epoll_wait(8` with no completed rapid returns.

The relevant local code path is `ServerLoop()` using `DetermineSleepTime()` and PostgreSQL’s wait/latch helpers: `WaitEventSetWait()`, `SetLatch()`, and `ResetLatch()`. That matches the documented latch convention in `src/include/storage/latch.h`. I followed the saved plan and did not change course: without stronger evidence, an upstream source patch would be speculative and could regress postmaster responsiveness.

No code change was made. The expected effect is no behavior change; this diagnosis should instead be used as an upstream report asking for a trace that proves repeated completed `epoll_wait()` wakeups before proposing a patch.

No source patch is proposed. The collected trace points at rsync waiting in its normal timeout-driven IO loop, not at a demonstrated busy-poll loop.

Fixer reported a likely busy-poll runaway, but the collected signal is contradictory: the sampled process was `S (sleeping)`, `wchan` was `poll_schedule_timeout`, strace captured one `pselect6()` over 5 seconds with about 59 seconds left in the timeout, and total CPU was about 0.3% across 8 rsync processes.

The cautious code-level inference is that this is rsync’s normal IO wait path. In `io.c`, `set_io_timeout()` caps periodic waits at `SELECT_TIMEOUT` and `perform_io()` passes that timeout to `select()`, while `check_timeout()` and `maybe_send_keepalive()` handle timeout/keepalive behavior. A 59-second `pselect6()` timeout is consistent with that design for `--timeout=300`.

I followed the saved plan and made no source changes. The expected effect is no behavioral change: this avoids sending an upstream patch that could regress long-running transfers without evidence of immediate repeated wakeups. Project guidance found `README.md`; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` were present. Relevant local helpers/conventions include `perform_io()`, `set_io_timeout()`, `check_timeout()`, `maybe_send_keepalive()`, `rprintf()`, `rsyserr()`, and `exit_cleanup()`.

No OpenSSH source change is proposed. The collected perf, strace, and `/proc` evidence points at an `sshd-session` process sleeping in `poll(2)`, not at a demonstrated userspace spin loop. Changing the session loop or monitor loop from this signal alone would risk altering normal idle SSH session behavior.

I followed the saved plan and did not change course. I checked `README.md`; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` were present. Relevant local conventions include `fatal_f`/`error_f`, `xmalloc`, `atomicio`, and `ptimeout_*` for poll/ppoll deadlines.

The collected signal was a Fixer runaway-process report for `/usr/lib/openssh/sshd-session`, but the details show `State: S (sleeping)`, `wchan=poll_schedule_timeout.constprop.0`, a single `restart_syscall(<... resuming interrupted poll ...>)` line over 5 seconds, and only 0.7% max CPU for the sampled process.

The cautious code-level inference is that the process was blocked in a normal OpenSSH wait path, either the server session loop’s `ppoll(2)` wait in `serverloop.c` or the privileged monitor’s `poll(2)` wait in `monitor.c`. The evidence bundle does not include symbolized OpenSSH frames or fd targets, and the referenced raw artifacts are missing from disk, so there is not enough information to identify a faulty OpenSSH control path.

The specific change made is no source change. This avoids presenting an inferred mitigation as a confirmed bug fix. The expected effect is no runtime behavior change; the next useful upstream report should include symbolized backtraces, fd targets, and a sample showing repeated wakeups rather than an idle `poll`.

No source change is proposed. The collected signal points at the postmaster sleeping in PostgreSQL’s existing wait-event path, not at a confirmed busy loop. The relevant code already uses the local `WaitEventSetWait()`, `AddWaitEventToSet()`, `DetermineSleepTime()`, and `ResetLatch()` helpers.

Fixer reported a possible runaway `postgres` process based on a perf profile and a backtrace ending in `WaitEventSetWait()` and `epoll_wait()`. The `/proc` evidence says the process was sleeping in `do_epoll_wait`, and the strace excerpt contains one unfinished `epoll_wait` over the capture window, with only about 0.7% total CPU across postgres processes.

The cautious inference is that the sampled postmaster was idle in its normal event wait, not spinning. PostgreSQL’s postmaster uses a `WaitEventSet`, meaning a registered set of latch and socket events, to sleep until a signal, timeout, or incoming connection needs service. I did not make a source change because changing this path without evidence of repeated immediate wakeups would be speculative and could harm normal postmaster latency or latch behavior.

The expected effect is no runtime change: this is a no-patch diagnosis suitable for an upstream bug report only if stronger evidence is collected, such as repeated completed `epoll_wait()` calls with near-zero delay and measurable CPU.

No source change. The collected signal points at the PostgreSQL postmaster sleeping in `epoll_wait`, not at a proven busy loop. The relevant code already uses PostgreSQL’s `WaitEventSet` wait abstraction, with the postmaster sleep bounded by `DetermineSleepTime()`.

The likely root cause from the perf, strace, and `/proc` evidence is a false positive in the busy-poll classification. Fixer sampled the postmaster in `WaitEventSetWait()` and then `epoll_wait`, but `/proc` reported state `S (sleeping)`, `wchan=do_epoll_wait`, total CPU around 0.7%, and strace captured only one `epoll_wait` line over five seconds rather than repeated immediate returns.

At code level, the implicated path is the normal postmaster idle loop: `ServerLoop()` calls `WaitEventSetWait()` with `DetermineSleepTime()`, and `DetermineSleepTime()` bounds normal sleeps to 60 seconds. `WaitEventSet` is PostgreSQL’s local portability helper for epoll/poll/kqueue/Win32 waiting, so replacing or bypassing it would be less upstreamable than using the existing abstraction.

I followed the saved plan and did not change course: without stronger evidence showing repeated zero-duration wakeups, there is no safe source patch to land. No explanatory source comment was added because there is no non-obvious new logic.

The expected effect of leaving the tree unchanged is to avoid a speculative change that could delay shutdown, reload, child-exit handling, or connection acceptance in the postmaster.

No source change was made. The collected evidence does not identify a pull-request-ready OpenSSH bug: the sampled `sshd-session` was in sleeping state `S`, blocked in `poll`/`restart_syscall`, while the only named hot userspace symbol was `adler32_z` from zlib. That points to an inconclusive profile, possibly recent SSH compression work or sampling attribution noise, not a demonstrated busy loop in OpenSSH.

I followed the saved plan and stopped at diagnosis. `README.md` documents the normal `./configure`/`make` workflow; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` entry was found. The relevant local conventions are `sshbuf_*`, `ssh_packet_*`, `ptimeout_*`/`monotime`, `ppoll`, `xmalloc`, and `fatal_f`/`fatal_fr`/`sshpkt_fatal`.

Fixer collected a runaway-process signal for `sshd-session`: a 3-second profile reported `adler32_z` at 11.40%, one strace line showed `restart_syscall(<... resuming interrupted poll ...>`, `/proc` reported state `S (sleeping)`, and `wchan` was `poll_schedule_timeout.constprop.0`.

The cautious code-level inference is that OpenSSH was not proven to be spinning. `serverloop.c` intentionally sleeps in `ppoll()` via `wait_until_can_do_something()`, and zlib is only reached through packet compression in `packet.c`; the available backtrace lacks symbolized OpenSSH frames tying `adler32_z` to a loop.

The specific change made is none. I did not leave a source diff because the evidence is profiler-only/indirect and the raw artifact directory referenced by the bundle is absent, preventing stronger symbolization. The expected effect is to avoid an upstream patch that would guess at compression or event-loop behavior without proof.

No source change is proposed. The collected evidence points to rsync sleeping in its normal `select`-based I/O wait path, not to a confirmed busy-poll loop. A source patch would be speculative without a longer trace showing immediate poll wakeups or a symbolized stack that identifies a concrete rsync loop.

The collected signal is a Fixer profiler finding that classified rsync as a likely busy-poll process. The supporting `/proc` and trace data show a sleeping process (`State: S`), `wchan: poll_schedule_timeout`, total CPU around `0.2%`, and a `pselect6` call that blocked for about `2.49s` before one 8-byte `read`.

The cautious code-level inference is that this matches rsync’s established `io.c` I/O wait machinery: `perform_io()` and `safe_read()` wait in `select()`, while `set_io_timeout()`, `check_timeout()`, `maybe_send_keepalive()`, `read_buf()`, and `io_flush()` manage timeout and keepalive behavior. `README.md` was the only matching contribution/style document found, and nearby code uses rsync helpers such as `rprintf()`/`rsyserr()` for diagnostics.

I made no source change. This follows the saved plan rather than drifting from it: the independent checks did not produce stronger observed or reproduced evidence. The expected effect is to avoid an upstream-unready patch that could regress long-running transfers or receiver/generator timeout coordination.

`supervisord` reaped children on every main-loop tick, even when it had no tracked child PIDs and no queued SIGCHLD signal. SIGCHLD is the Unix signal delivered when a child process exits. The loop now handles pending signals first and only calls the existing `ServerOptions.waitpid()` wrapper when SIGCHLD was seen or `pidhistory` contains tracked children.

Fixer observed `/usr/bin/supervisord` running under Python 3.13 with strace samples repeatedly showing `wait4(-1, WNOHANG) = -1 ECHILD` followed by a one-second `poll`. `/proc` evidence showed the process sleeping in `poll`, and the interpreter evidence identified `supervisord` as the script entrypoint, so this patch targets Supervisor rather than the Python runtime.

The code-level cause is that `Supervisor.runforever()` called `reap()` on every loop. `reap()` delegates to the local `ServerOptions.waitpid()` helper, so an idle supervisor with no child processes still asks the kernel for child status each tick and receives `ECHILD`.

I changed the loop to call `handle_signal()` first, have it return the handled signal, and call `reap()` only when the handled signal is SIGCHLD or Supervisor has tracked child PIDs in `options.pidhistory`. The expected effect is to avoid idle `waitpid`/`ECHILD` churn while preserving reaping for known children and for SIGCHLD-driven unknown child exits. This failure was observed by Fixer and not independently reproduced with strace locally because ptrace is blocked in this sandbox.

I followed the existing maintainer conventions in `docs/development.rst` and nearby subsystem code: no new platform API was introduced, and the patch keeps using `SignalReceiver` and `ServerOptions.waitpid()`.

No source change was made. The collected perf, strace, and `/proc` evidence points to `supervisord` running under Python, not to a demonstrated CPython polling or wait bug. CPython’s local `select.poll()` and `os.wait4()` paths already use the project’s established helpers for releasing the GIL and handling interrupted syscalls.

Fixer observed `/usr/bin/python3 /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf` with high CPU attributed to `python3.13`. The collected signal shows repeated `wait4(-1, ..., WNOHANG) = ECHILD` calls followed by `poll(..., 1000) = 0` timeouts, while `/proc` reports the sampled thread sleeping in `poll_schedule_timeout`.

The cautious code-level inference is that this is Supervisor’s event loop or deployment state waking once per second to reap child processes and poll its control fd. The CPython code I inspected does not show a matching runtime defect: `Modules/selectmodule.c` wraps `poll()` with `Py_BEGIN_ALLOW_THREADS`, handles `EINTR`, and recomputes deadlines with `_PyDeadline_Get`; `Modules/posixmodule.c` wraps `wait4()` similarly and uses `posix_error()` / `wait_helper()`.

I followed `./plan-output.txt` and did not change course. Because the evidence does not establish a CPython API or implementation failure, I made no source change. The expected effect is avoiding a speculative upstream CPython patch and leaving a focused diagnosis suitable for redirecting the bug report toward Supervisor or the service configuration.

No source change is proposed. The collected perf, strace, and `/proc` evidence points at an `sshd-session` privilege-separation monitor sleeping in `poll`, not at a confirmed OpenSSH userspace busy loop.

The collected signal was `sshd-session: gis [priv]` with a backtrace through libc `poll`, `/proc` state `S (sleeping)`, `wchan=poll_schedule_timeout.constprop.0`, one `restart_syscall` strace line over 5 seconds, and only `0.3%` total CPU across sampled `sshd-session` processes. The sampled hot symbols are kernel memory-management paths, not symbolized OpenSSH frames.

The cautious inference is that this is normal privilege-separation monitor behavior. In OpenSSH, privilege separation keeps a privileged monitor process available for root-only operations; nearby `monitor_read()` intentionally blocks with `poll(..., -1)`, and `server_loop2()` sleeps in `ppoll()` using the local `ptimeout_*` helpers.

I made no source change and did not apply the prior `buildpkg.sh` patch, because that patch is unrelated to the sshd-session evidence. Docs/conventions checked: `README.md`; subsystem helpers checked include `fatal_f`/`error_f`/`debug_f`, `ssh_signal()`, `xmalloc`, `atomicio`, `ptimeout_*`, and OpenSSH poll/ppoll compatibility wrappers.

The expected effect is to avoid sending an upstream-hostile speculative patch until there is symbolized or reproducible evidence of an actual OpenSSH busy loop.

No source change. The collected perf, strace, and `/proc` evidence points at a sleeping postmaster inside PostgreSQL’s `WaitEventSet` wait path, but it does not prove a busy-poll loop. The prior Fixer patch was generated build output, not an upstreamable source fix.

Fixer reported `postgres` as a likely busy-poll loop: the sampled stack reached `PostmasterMain()`, `WaitEventSetWait()`, and `epoll_wait()`, while `hash_search_with_hash_value` was the hottest PostgreSQL symbol. The same evidence says the process was sleeping, `wchan` was `do_epoll_wait`, CPU was low, and the strace excerpt contains only one unfinished `epoll_wait(8` line.

The cautious code-level inference is that the postmaster was normally blocked in PostgreSQL’s `WaitEventSet` abstraction, not confirmed to be spinning. I inspected the relevant postmaster paths, including `DetermineSleepTime()`, `ServerLoop()`, and `maybe_start_bgworkers()` in `src/backend/postmaster/postmaster.c`, plus the wait-event implementation in `src/backend/storage/ipc/waiteventset.c`. The local helpers/conventions are `CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, `ResetLatch()`, and server logging via `ereport`/`elog`.

I made no code change because the evidence is indirect and I could not independently reproduce repeated immediate-return `epoll_wait` calls. The expected effect is to avoid an upstream-unready behavioral change until a real nonblocking postmaster loop is demonstrated. I followed the saved plan and rejected the prior Fixer patch because it adds generated artifacts such as `GNUmakefile`/`objfiles.txt` rather than a source fix.

No source change is proposed. The collected evidence points to an idle postmaster waiting through PostgreSQL’s wait-event set, the local abstraction around `epoll_wait()` and latch wakeups, rather than to a demonstrated PostgreSQL busy loop.

Fixer reported a likely runaway `postgres`, but the evidence shows low sampled CPU (`max_cpu_percent` 0.8, total 1.0 across 9 processes), process state `S (sleeping)`, `wchan=do_epoll_wait`, a stack in `epoll_wait()` via `WaitEventSetWait()`, and only one unfinished `epoll_wait(8` line during a 5-second strace. The likely root cause is an over-classified profiler signal, not a confirmed PostgreSQL source bug.

The relevant code already uses PostgreSQL’s local wait helpers: `ConfigurePostmasterWaitSet()`, `DetermineSleepTime()`, `ServerLoop()`, `WaitEventSetWait()`, `AddWaitEventToSet()`, `ResetLatch()`, and signal-driven `SetLatch()` behavior. The latch documentation explicitly warns that wait/reset ordering is race-sensitive, so adding sleeps, changing latch flow, or introducing generic syscall workarounds would be speculative and risky.

I followed the saved plan and did not carry forward the prior Fixer patch. That prior patch consists of generated build artifacts such as `GNUmakefile`, `objfiles.txt`, and generated parser/scanner files; it is not an upstreamable source fix. The expected effect of this no-patch result is to avoid adding latency or disturbing postmaster wakeup semantics without stronger observed or reproduced evidence.

`channel_prepare_pollfd()` translates channel I/O wants into `pollfd` events for the client and server loops. The branch for a channel socket fd distinct from `rfd` computed the requested readiness mask, but registered the fd with `events = 0`.

Store the computed mask for that socket fd, matching the adjacent `rfd`, `wfd`, and `efd` branches, so `ppoll()` is armed for the readiness the channel requested.

Fixer observed `sshd-session` around `poll`/`restart_syscall`, with `/proc` showing `wchan` in `poll_schedule_timeout`; this was observed by Fixer and not independently reproduced. The evidence points at the session event loop, but does not prove the sampled process took this exact channel path.

The concrete code issue is in the channel poll preparation path: `channel_prepare_pollfd()` computes `ev` from `SSH_CHAN_IO_SOCK_R` and `SSH_CHAN_IO_SOCK_W` for a distinct `c->sock`, then discarded it by setting `pfd[p].events = 0`. I changed that assignment to `pfd[p].events = ev`, following existing channel-loop conventions and helpers: `SSH_CHAN_IO_*`, `channel_prepare_poll()`, `channel_after_poll()`, `fd_ready()`, `dump_channel_poll()`, `xrecallocarray()`, `fatal_f()`, and `ptimeout_*`.

The expected effect is that distinct channel sockets are actually armed in `ppoll()` for requested input/output readiness instead of being added as inert poll entries. Review round 1 found generated regress artifacts in the worktree; I removed those unintended validation files so the shipped patch contains only `channels.c`. Only `README.md` was found among the requested contribution/style docs.

No source change was made. The collected profile and trace data do not identify a pull-request-ready rsync bug, and the prior Fixer patch only added unrelated `lib/dummy` content.

Fixer sampled an `rsync --server -logDtpRze.LsfxCIvu ...` process with 20.96% of sampled CPU in `XXH3_64bits_update`, but the same evidence shows the process sleeping in `pselect6`, `wchan` as `poll_schedule_timeout`, one captured `pselect6(..., {tv_sec=11,...})`, and only 4.3% CPU during the short profile.

The likely root cause cannot be pinned to rsync from this evidence. The cautious reading is that Fixer caught normal checksum/compression work near an I/O wait, or an incomplete trace of an active transfer, not a proven busy-poll loop. I followed the saved plan and did not change course.

I reviewed the prior patch and rejected it: adding `lib/dummy` is unrelated to the profile signal. I also checked rsync conventions: relevant helpers are `rprintf()`, `rsyserr()`, `exit_cleanup()`, `new_array()`/`realloc_array()`/`out_of_memory()`, `do_open_checklinks()`, `map_file()`, `unmap_file()`, `maybe_send_keepalive()`, and `sum_init()`/`sum_update()`/`sum_end()`. Style docs found were `README.md`, `INSTALL.md`, and `testsuite/README.testsuite`; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` were present.

The specific change made is none, because an inferred source patch would not be upstream-ready. The expected effect is to avoid changing rsync I/O or checksum behavior until stronger evidence exists, such as symbolized rsync frames, repeated immediate poll/select wakeups without progress, or a local reproducer.

No source change is proposed. The collected perf, strace, and `/proc` evidence most likely shows OpenSSH’s bounded failed-authentication delay followed by monitor IPC, not a proven runaway loop in `sshd-auth`.

Fixer reported `sshd-auth` as timer churn, but the captured process had 0.1% CPU, state `S (sleeping)`, `wchan` `unix_stream_read_generic`, and a kernel stack blocked in Unix socket read. The strace excerpt shows one `clock_nanosleep`, monitor/log writes, and then another blocking `read`.

The cautious code-level explanation is that this matches `auth2.c:ensure_minimum_time_since()`, OpenSSH’s bounded delay after failed non-`none` authentication, followed by monitor IPC through helpers such as `mm_request_send()` / `mm_request_receive_expect()`. I reviewed the prior Fixer patch and discarded it: adding generated `buildpkg.sh` is unrelated to this signal.

I made no source change because the evidence is indirect and the independent smoke test was blocked before authentication. The expected effect is no runtime behavior change and no speculative weakening of OpenSSH’s authentication timing behavior. Relevant local conventions found: README asks for OpenBSD style; nearby code uses `sshbuf`, `atomicio`, `fatal_f`/`fatal_fr`, `debug*_f`, `xmalloc`, and `freezero`.

No source patch is proposed. The collected perf, strace, and `/proc` evidence points to a sleeping `sshd-session` blocked in `poll`, while CPU attribution is in the kernel `i40e` network driver, so there is not enough evidence for an upstream OpenSSH source change.

The collected signal is a Fixer runaway-CPU investigation for `sshd-session`: perf attributed the sampled hot path to `i40e_lan_select_queue`, strace saw only `restart_syscall(<... resuming interrupted poll ...>)`, and `/proc` reported state `S (sleeping)` with `wchan` at `poll_schedule_timeout`.

The likely root cause is outside the OpenSSH userspace event loop, or the sample is at least too indirect to prove an OpenSSH loop. The relevant server loop already sleeps through `ppoll()` using local OpenSSH helpers and conventions: `channel_prepare_poll()`, `channel_after_poll()`, `ptimeout_*()`, `ssh_packet_*()`, and `debug_f`/`logit`/`fatal_f`.

I made no source change. This follows the saved plan and replaces the prior Fixer attempt, whose patch added an unrelated generated `buildpkg.sh`; that diff should be dropped rather than cleaned up into an upstream patch. I found no `CONTRIBUTING`/`HACKING` docs, only `README.md` and `regress/README.regress` for build/test guidance.

The expected effect is a clean no-patch diagnosis suitable for an upstream report, instead of a speculative source change based on indirect profiler data.

No OpenSSH source change is included. The collected perf, strace, and `/proc` evidence points to an `sshd-session` process sleeping in `poll`, with hot samples in kernel/NSS/systemd paths rather than a confirmed OpenSSH event-loop bug.

Fixer reported `sshd-session` as a runaway-process investigation, but the collected signal is indirect: process state was `S (sleeping)`, `wchan` was `poll_schedule_timeout`, strace captured only `restart_syscall(<... resuming interrupted poll ...>)` over 5 seconds, and the profile target reported 0.1% total CPU across three `sshd-session` processes. The hottest samples were in kernel/NSS/systemd areas, including `security_inode_alloc`, `_raw_spin_lock_irqsave`, `do_epoll_ctl`, and `libnss_systemd.so.2`.

The cautious inference is that the sampled OpenSSH process was blocked in a normal poll wait, while the profiler attribution came from activity outside a symbolized OpenSSH frame. I inspected the relevant session and event-loop code and found it already follows local OpenSSH conventions: `serverloop.c` uses `ptimeout_*`, `channel_prepare_poll`, and `ppoll`; `monitor.c` uses blocking `poll`; nearby code uses `fatal_f`/`fatal_fr`, `debug*`/`logit`, `sshbuf`, `xmalloc`/`xrecallocarray`, and `openbsd-compat` wrappers. README/README.md point contributors to OpenBSD style.

I made no source change. This replaces the prior Fixer patch attempt: its diff added an unrelated `buildpkg.sh`, which is not connected to the observed `sshd-session` signal and should not be carried forward. The expected effect is no runtime behavior change; this avoids landing a speculative upstream patch that could regress normal idle session behavior.

No source change was made. The collected evidence points at `sshd-session` blocked in the normal server poll loop, not at a confirmed OpenSSH busy loop.

Fixer collected a profiler/trace bundle labelled as runaway CPU, but the concrete signals conflict with that label: `/proc` reported `S (sleeping)`, `wchan` was `poll_schedule_timeout.constprop.0`, `strace` captured only one resumed `poll`, and the profile target reported `0.1%` total CPU across three `sshd-session` processes.

The likely code path is OpenSSH’s post-auth server loop in `server_loop2()` waiting via `wait_until_can_do_something()`. That subsystem already uses local helpers and conventions including `ptimeout_*()`, `monotime()`, `channel_prepare_poll()`, `channel_after_poll()`, and `ssh_signal()`. With only indirect evidence, changing timeout or wakeup behavior would be speculative and not pull-request-ready.

I made no source change and did not carry forward the prior Fixer patch, which deleted unrelated `contrib/hpux/sshd`. The expected effect is no behavioral change: this avoids risking keepalive, rekey, child cleanup, channel I/O, or idle-timeout behavior without a reproduced or directly observed OpenSSH spin.

Only `README.md` was found among the requested contribution/style docs.

No source change was made. The collected signal is better explained as PostgreSQL’s normal postmaster idle wait path than as a demonstrated busy loop: the postmaster was sleeping in `epoll_wait` through `WaitEventSetWait()`, PostgreSQL’s wait/latch abstraction for sleeping on latches and sockets.

The likely root cause is an over-classification of a poll-family wait frame as busy polling. The evidence reports `postgres` as likely runaway, but the concrete signals show `PostmasterMain()` -> `WaitEventSetWait()` -> `epoll_wait()`, process state `S (sleeping)`, `wchan` as `do_epoll_wait`, one recorded `epoll_wait` line over 5 seconds, and total sampled CPU under 1%. The `AllocSetAlloc` hotspot was 6.92% of an already-low sample and does not identify a source-level loop.

The cautious code-level inference is that this is the normal postmaster server loop. `ServerLoop()` computes a bounded timeout with `DetermineSleepTime()` and waits with local helpers including `WaitEventSetWait()`, `AddWaitEventToSet()`, and `ResetLatch()`. That path also has a deliberate zero-timeout poll only after a latch event, to coalesce immediately ready non-latch events.

I followed the saved plan and made no source change. I also reviewed the prior Fixer patch; it should be replaced rather than refined because it contains generated build artifacts and an unrelated bootstrap parser memory-context change.

The expected effect is no runtime behavior change. This avoids a speculative throttle or control-flow change in the postmaster accept, shutdown, reload, child-exit, and background-worker path without stronger evidence of a real loop.

No source change is proposed. The collected perf, strace, and `/proc` evidence most closely matches normal pre-authentication failure pacing: `sshd-auth` handles an auth request, sleeps before sending failure, writes a response, then returns to waiting. The process was sleeping with about `0.1%` CPU, so the evidence does not prove runaway CPU or an OpenSSH bug.

Reviewed `README.md`; no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` were present. Relevant local conventions in this subsystem include `debug*_f`, `fatal_fr`, `sshbuf`, `atomicio`, `ssh_msg_send/recv`, `xmalloc`, `freezero`, `monotime_double()`, and the existing direct `nanosleep()` delay. `ptimeout` exists for poll/ppoll timeouts, but no relevant local helper was found for replacing this deliberate sleep.

Fixer collected a timer-related signal for `sshd-auth: unknown [net]`: strace showed `read`, `clock_nanosleep`, and `write`; `/proc` showed state `S (sleeping)` and `wchan` `unix_stream_read_generic`; the sampled CPU was about `0.1%`. This is indirect evidence of possible timer churn, not a reproduced runaway loop.

The cautious code-level inference is that the trace matches `auth2.c` failed-authentication pacing. After a failed non-`none` userauth request, `input_userauth_request()` calls `ensure_minimum_time_since()`, which uses `monotime_double()` and `nanosleep()` to preserve minimum failure timing and reduce account-enumeration timing signals.

I made no source change. I also rejected the prior Fixer patch because it adds an unrelated Solaris packaging script, `buildpkg.sh`, and does not touch `sshd-auth`, authentication delay, monitor IPC, or the observed signal. This follows the saved plan; validation did not produce stronger evidence.

The expected effect is no runtime change. This leaves a maintainer-facing diagnosis instead of a speculative patch to a security-sensitive authentication delay.

No source change is made. The likely root cause is an indirect profiler classification: samples were collected below `epoll_wait()` in kernel idle scheduling, while `/proc` showed the postmaster sleeping in `do_epoll_wait` and strace captured only one unfinished `epoll_wait` call.

`WaitEventSet` is PostgreSQL’s local abstraction for waiting on latches and sockets. The inspected postmaster path already uses the expected helpers: `CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, `MyLatch`, `SetLatch()`, `ResetLatch()`, and `elog`/`ereport`.

The collected signal was a Fixer runaway-process report for `postgres`, with a backtrace through `WaitEventSetWait()` into `epoll_wait()`, process state `S (sleeping)`, `wchan` `do_epoll_wait`, low sampled CPU, and a single incomplete strace line: `epoll_wait(8`.

The cautious inference is that the postmaster was blocked normally in its event loop, not spinning. The evidence does not show repeated completed `epoll_wait()` calls, zero-timeout polling, high PostgreSQL CPU, or a concrete source condition in `DetermineSleepTime()` or `WaitEventSetWait()` that would cause a busy loop.

I followed the saved plan and made no source change. I also rejected the prior Fixer patch artifact because it contains generated build output such as `GNUmakefile` and many `objfiles.txt` files rather than an upstreamable source fix. The expected effect is to avoid changing postmaster signal, latch, or socket-wait behavior without proof of a PostgreSQL defect.

Contribution/style docs checked: `README.md`, `.github/CONTRIBUTING.md`, and `src/tools/pgindent/README`.

Redis samples RSS, the resident set size memory reported by the OS, through `/proc/self/stat` on Linux. Keep a cached proc stat file descriptor and read it with `pread()` so the periodic memory sampler does not reopen the same proc file on every server cron tick.

The cached descriptor is reopened after fork, because an inherited fd refers to the parent process’ concrete `/proc/<pid>/stat` file.

Fixer observed a sleeping Redis process repeatedly returning from `epoll_wait` and then doing `openat`, `read`, and `close` on `/proc/self/stat` about every 100 ms. This failure signal was observed by Fixer and not independently reproduced.

The code-level cause is the Linux RSS helper path: `serverCron()` calls `cronUpdateMemoryStats()`, which calls `zmalloc_get_rss()`, which used `get_proc_stat_ll()` to open and close `/proc/self/stat` for each sample. I changed `get_proc_stat_ll()` to use a small cached fd opened with `O_CLOEXEC`, read via `pread()`, and reopened when `getpid()` changes after fork. I added a short source comment explaining that fork invariant.

This improves the prior Fixer patch by preserving Redis’ existing memory-stat sampling cadence instead of making cached memory stats staler. The expected effect is to remove the repeated `/proc/self/stat` open/close churn while keeping RSS samples updated as before.

Perl's four-argument `select` converts a Perl timeout value to `struct timeval`, the seconds/microseconds structure passed to the platform `select` call. A strictly positive timeout below one microsecond was truncated to `0s, 0us`, making it behave like an explicit non-blocking poll. Preserve that distinction by rounding such tiny positive timeouts up to one microsecond.

Fixer observed `/usr/bin/perl` using CPU with samples in `Perl_runops_standard` and repeated `pselect6`, consistent with a busy poll loop. That failure was observed by Fixer and not independently reproduced because the evidence bundle has no script entrypoint, command line, or full strace body.

The cautious runtime-side cause addressed here is in `pp_sselect`: a positive Perl timeout smaller than one microsecond was truncated to a zero `struct timeval`, so `PerlSock_select` received a zero-time poll. I changed the conversion to keep the original non-negative timeout and set `tv_usec` to `1` when truncation would otherwise erase a positive timeout. I also fixed the local `Time::HiRes` test guard and added a regression in `t/op/sselect.t`.

The expected effect is that tiny positive `select` timeouts no longer spin as immediate polls. The patch follows the existing subsystem helpers and conventions already in `pp_sselect`, including `SvGETMAGIC`, `SvNV_nomg`, `PerlSock_select`, `Zero`, `Newx`, `Safefree`, `SvSETMAGIC`, and `SvSetMagicSV`; no new platform or allocation API was introduced. The prior Fixer patch was improved by using a more realistic timing threshold for the one-microsecond minimum.

Fixer observed `sshd-auth`, the split helper that handles pre-authentication SSH key exchange and user authentication, in a short trace around sleep, monitor writes, and `ppoll`. The trace does not prove an infinite spin, but it does show the pre-auth helper in the area that should be bounded by `LoginGraceTime`.

`sshd-session.c` already arms that timer before pre-authentication. Mirror that bounded timer setup in `sshd-auth.c`, and clear it after authentication succeeds.

Fixer observed an `sshd-auth: root [net]` process with profiler evidence in `sshd-auth`, a dominant syscall sequence of `clock_nanosleep`, `write`, and `ppoll`, `/proc` state sleeping in `unix_stream_read_generic`, and a captured strace ending with `ECONNRESET` and exit. This was observed by Fixer and not independently reproduced.

The cautious code-level cause is that split `sshd-auth.c` reset `SIGALRM` to the default action and then entered key exchange and authentication without arming the configured `LoginGraceTime` alarm. I improved the prior Fixer patch by keeping the same bounded linear control flow, cleaning up style, and adding only the timer setup/clear logic already used by the nearby session path.

The change uses existing OpenSSH conventions and helpers: `ssh_signal`, `setitimer`, `timerclear`, `arc4random_uniform`, `fatal`, and `_exit(EXIT_LOGIN_GRACE)`. `README.md` was the only contribution/style document found; no relevant local file-I/O, path, process-spawn, allocation, or locking helper was needed for this change. The expected effect is that slow or wedged `sshd-auth` pre-authentication workers are terminated by the configured login grace timeout instead of being allowed to remain in pre-authentication indefinitely.

Redis samples process RSS, resident set size, from `serverCron()`, the periodic maintenance loop. On Linux this calls `zmalloc_get_rss()`, which reads `/proc/self/stat`; doing that on the 100 ms allocator-stat cadence creates steady procfs traffic even when Redis is idle.

Sample process RSS once per second instead, while keeping allocator stats on the existing 100 ms cadence. Keep `process_rss` and `zmalloc_used` sampled together because Redis uses their ratio for total memory fragmentation reporting.

Fixer observed a `redis-server` process repeatedly returning from `epoll_wait` and then doing `openat`/`read`/`close` on `/proc/self/stat`. This failure signal was observed by Fixer and not independently reproduced locally because `strace`/ptrace is blocked in this sandbox.

The code-level cause matches the collected trace: `serverCron()` calls `cronUpdateMemoryStats()`, and that function sampled `zmalloc_get_rss()` every 100 ms. On Linux, `zmalloc_get_rss()` reads `/proc/self/stat`.

I changed `src/server.c` so process RSS sampling uses Redis’ existing `run_with_period(...)` cron convention on a 1000 ms cadence, while allocator stats stay on the existing 100 ms cadence. The code continues using the local `zmalloc_get_rss()`, `zmalloc_used_memory()`, and allocator-stat helpers; I found no relevant local procfs file-IO wrapper to use instead. I also added a short comment explaining the invariant that RSS and `zmalloc_used` must stay paired for the fragmentation ratio.

The expected effect is to reduce idle `/proc/self/stat` reads from Redis’ memory telemetry path without changing the generic RSS reader or Debian packaging. I reviewed `CONTRIBUTING.md`, `README.md`, the prior Fixer patch, and the local memory/cron helpers before editing.

The pre-authentication failure delay groups failed authentication attempts into coarse timing buckets. If an authentication backend was already slow, the catch-up loop could still double the target delay until it passed elapsed time, then add a large extra sleep.

Keep the bucketed timing behavior, but cap extra catch-up padding after slow backend work. This preserves the existing timing mitigation while avoiding second-scale sleeps after already slow failed authentication attempts.

Fixer observed `sshd-auth: root [net]` sleeping with a backtrace through `nanosleep()`/`clock_nanosleep()` and strace showing a `read, read, clock_nanosleep` sequence with sleeps around 1.5-1.8 seconds. This failure was observed by Fixer and not independently reproduced.

The cautious code-level connection is `auth2.c`’s pre-authentication failure delay. “Pre-authentication” here means the server-side phase before a login session is accepted. `ensure_minimum_time_since()` already grouped failed auth attempts into timing buckets, but its catch-up loop could add a large delay after backend work had already exceeded the initial 5-9ms per-user delay.

The patch adds a 250ms cap for that extra catch-up padding while keeping the existing bucket loop. The expected effect is to reduce avoidable long post-auth sleeps while retaining coarse timing equalization for failed authentication. I kept the refined prior Fixer approach, avoided new `goto` flow, and added a short comment describing the invariant.

I checked `README`, `README.md`, and the touched auth subsystem. The change follows local OpenSSH conventions and existing helpers: `monotime_double()`, `debug3_f()`, `fatal_f()`, `xmalloc()`, `freezero()`, and the existing direct portable `nanosleep()` use in this helper. No relevant higher-level sleep helper was found, and no new file, process, allocation, locking, networking, or platform APIs were introduced.

No source change is proposed. The collected perf, strace, and `/proc` evidence points to a privileged `sshd-session` monitor blocked in `poll`, not to a confirmed OpenSSH userspace loop. Carrying the prior `buildpkg.sh` patch forward would add unrelated packaging code and would not address the collected signal.

The collected signal is a Fixer profiler snapshot for `sshd-session: gis [priv]`: perf sampled kernel `dup_mmap`, strace saw only `restart_syscall(<... resuming interrupted poll ...>)`, `/proc` reported `S (sleeping)`, and `wchan` was `poll_schedule_timeout`.

The cautious code-level inference is that this process was in OpenSSH’s privileged monitor path, where `monitor_child_postauth()` loops through `monitor_read()`, and `monitor_read()` blocks in `poll(..., -1)` waiting for monitor or log messages. The `dup_mmap` hotspot is more consistent with fork/clone memory-management work elsewhere than with the captured thread spinning in userspace.

I made no source change. This follows the saved plan because the evidence remains indirect, the raw investigation directory is unavailable, and the bounded smoke check did not reproduce the collected CPU/poll signal. The expected effect is no runtime change; this avoids sending an upstream patch for normal monitor blocking behavior without a demonstrated OpenSSH bug.

Relevant local conventions found: `fatal_f`/`fatal_fr`, `debug*_f`, `sshbuf`, `xmalloc`/`xcalloc`, `atomicio`, `ssh_signal`, `ptimeout_*`, and platform fork hooks such as `platform_pre_fork()` / `platform_post_fork_*()`. Only `README.md` was found among the requested contribution/style docs.

No source change is proposed. The collected evidence points to an idle PostgreSQL postmaster blocked in `epoll_wait()`, not to a demonstrated busy-polling bug in PostgreSQL’s wait-event code.

The collected signal was a perf/profile report classifying `postgres` as a likely busy poll loop, with a backtrace through `WaitEventSetWait()` into `epoll_wait()`. The `/proc` evidence says the process was sleeping, `wchan` was `do_epoll_wait`, CPU was low, and the 5-second strace captured only one unfinished `epoll_wait(8...` line.

The cautious inference is that Fixer observed the normal postmaster idle loop rather than a proven source defect. PostgreSQL’s postmaster registers its latch and listen sockets through local helpers such as `ConfigurePostmasterWaitSet()`, `CreateWaitEventSet()`, `AddWaitEventToSet()`, `WaitEventSetWait()`, `ResetLatch()`, and `DetermineSleepTime()`. I found no helper bypass or awkward control flow that should be patched from this evidence.

I made no source change. The expected effect is that this proposal avoids an upstream-unready patch to central wait/latch code until there is direct evidence of repeated immediate `epoll_wait()` returns.

I followed the saved plan and did not change course. The project guidance checked was `README.md` and `.github/CONTRIBUTING.md`; the latter points contributors to PostgreSQL’s developer site.

No source patch was left. The collected `/proc` evidence shows a bcachefs copygc kernel thread in uninterruptible sleep, with `wchan` at `submit_bio_wait` and a stack blocked in a synchronous btree-node read while flushing the btree write buffer. The likely root cause is lower-level storage I/O not completing; the evidence does not show a bcachefs-local deadlock, spin, or missed cancellation path that can be fixed safely with a narrow upstream patch.

Fixer observed `bch-copygc/...` in `D (disk sleep)` for about 260164 seconds, with the stack `submit_bio_wait -> bch2_btree_node_read -> wb_flush_sorted_range -> bch2_btree_write_buffer_tryflush -> __bch2_move_data_phys -> bch2_copygc_thread`. I did not independently reproduce the failure.

At the code level, copygc is the background “copy garbage collection” worker that evacuates fragmented buckets. Before scanning backpointers, `__bch2_move_data_phys()` flushes the btree write buffer; that flush may need to synchronously read a btree node, and the observed thread is blocked waiting for that block I/O to complete. The evidence bundle also marks `likely_external_root_cause: true`, which is consistent with a bio stuck below bcachefs rather than bcachefs looping in CPU or waiting on one of its own wait queues.

I made no source change. The saved plan said not to patch from this evidence alone, and the code inspection did not prove that plan wrong. In particular, skipping `bch2_btree_write_buffer_tryflush()` would risk scanning stale backpointer state, and adding `kthread_should_stop()` checks around the call would not help a thread already blocked inside `submit_bio_wait()`.

The expected effect is a stronger upstream bug report rather than a speculative patch: the next useful evidence would be device-layer error/timeout logs, block trace output, or another live stack sample showing a bcachefs lock dependency rather than only uncompleted storage I/O. Local bcachefs conventions checked include `bch2_move_ratelimit()`, `bch2_trans_unlock_long()`, `bch2_err_matches()`, `bch_err_msg()`, `bch2_fs_fatal_err_on()`, `kthread_wait_freezable()`, and existing `kthread_should_stop()` / `freezing(current)` handling.

No source change is proposed. The collected perf, strace, and `/proc` data point to the postmaster sleeping in PostgreSQL’s wait-event subsystem, not to a demonstrated busy loop.

The prior Fixer patch was not upstreamable because it consisted of generated build artifacts. This response replaces it with a no-patch diagnosis.

The collected signal reported `postgres` as a likely busy-poll process, with the stack ending in `PostmasterMain()` -> `WaitEventSetWait()` -> `epoll_wait()`. The same bundle says the process was in state `S (sleeping)`, `wchan` was `do_epoll_wait`, strace captured only one `epoll_wait(` line over 5 seconds, and CPU was low (`max_cpu_percent: 0.7`).

The cautious code-level inference is that this is normal postmaster idle waiting unless stronger evidence shows repeated rapid wakeups. PostgreSQL’s latch, meaning its safe process wakeup primitive, is already handled through `WaitEventSetWait()`, `SetLatch()`, `ResetLatch()`, and `pg_memory_barrier()`. `ServerLoop()` also already uses `DetermineSleepTime()` to avoid blocking only when background-worker work is pending.

I made no source change and did not keep the prior generated-artifact diff. The expected effect is to avoid landing a speculative upstream patch that could delay connection accepts, shutdown/reload handling, child-exit processing, or background-worker startup without proof of a PostgreSQL defect.

No source patch is proposed. The available perf, strace, and `/proc` evidence points to a postmaster waiting in PostgreSQL’s `WaitEventSetWait()` latch/socket abstraction over `epoll_wait`, not to a demonstrated busy loop in PostgreSQL source.

The previous Fixer patch changed `ServerLoop()` signal handling, but review showed that the evidence did not establish the condition that patch addressed. I replaced it with a no-patch diagnosis.

The collected signal is a sampled `postgres` postmaster with a backtrace in `WaitEventSetWait()` over `epoll_wait`; `/proc` reported state `S (sleeping)` and wait channel `do_epoll_wait`. The profile also showed low total CPU for the postgres process group and only one captured strace syscall line in the evidence bundle.

The cautious inference is that this is likely normal postmaster wait or child-startup activity being classified as event-loop wakeups. The evidence does not show rapid repeated `epoll_wait` returns, repeated zero-timeout polling, multiple socket events being mishandled, or repeated processing of postmaster pending-signal flags.

The specific change I made was to leave the workspace with no source diff and reject the prior `src/backend/postmaster/postmaster.c` change as under-supported. PostgreSQL’s relevant local convention here is to stay within `WaitEventSetWait()`, `SetLatch()`, and `ResetLatch()` rather than adding raw platform polling APIs.

The expected effect is no behavior change. Stronger runtime evidence is needed before proposing an upstream source patch.

No source patch is included. The collected perf, strace, and `/proc` evidence points to the postmaster sleeping in PostgreSQL’s normal `WaitEventSetWait()` event loop, not to a confirmed busy-poll defect.

Fixer reported a likely runaway `postgres`, but the concrete signal is indirect: the sampled process was in `S (sleeping)`, `wchan` was `do_epoll_wait`, strace captured one unfinished `epoll_wait(8` over five seconds, and total CPU was about 0.8% across nine PostgreSQL processes.

The relevant code path is `ServerLoop()` using PostgreSQL’s local `CreateWaitEventSet`/`AddWaitEventToSet`/`WaitEventSetWait` latch and socket-wait abstraction. That path intentionally blocks in `epoll_wait()` until a latch, listening socket, or timeout wakes the postmaster. The evidence does not show repeated immediate-return `epoll_wait()` calls.

I made no source change. This follows the saved plan and replaces the prior generated-file patch artifact with a clean no-diff diagnosis. Style docs checked: `README.md`, `.github/CONTRIBUTING.md`, and nearby storage/postmaster code; no `HACKING` or `README-hacking` was present. The expected effect is no runtime behavior change and no upstream diff based on inferred evidence.

No source change was made. The collected perf, strace, and `/proc` evidence points more strongly to an idle postmaster blocked in PostgreSQL’s wait-event loop than to a confirmed PostgreSQL busy-poll bug.

The likely root cause from the collected evidence is a false-positive busy-poll classification of an idle postmaster. The bundle shows `PostmasterMain()` reaching `WaitEventSetWait()` and `epoll_wait()`, but also shows `State: S (sleeping)`, `wchan=do_epoll_wait`, only one captured `epoll_wait` line over five seconds, and about 0.8% total CPU across nine postgres processes.

The relevant code path is `ServerLoop()` in `src/backend/postmaster/postmaster.c`, which computes a sleep time with `DetermineSleepTime()` and waits through PostgreSQL’s `WaitEventSetWait()` abstraction in `src/backend/storage/ipc/waiteventset.c`. I found no demonstrated bad latch reset, socket event loop, or timeout calculation that would justify an upstream source change.

I followed the saved plan and replaced the prior Fixer attempt with a no-patch diagnosis. The prior patch mostly contained generated build artifacts such as `GNUmakefile` and `objfiles.txt`, which should not be submitted as an upstream fix. Local conventions inspected were `WaitEventSetWait()`, `AddWaitEventToSet()`, `ResetLatch()`, `MemoryContextAllocZero()`, `AcquireExternalFD()`/`ReleaseExternalFD()`, and `elog()`/`ereport()`. The expected effect is no behavioral change, avoiding a speculative patch without evidence of repeated rapid wakeups.

No source change is made. The collected evidence points at an idle PostgreSQL postmaster blocked in the wait-event subsystem, not at a demonstrated busy loop. A wait event is PostgreSQL’s abstraction for sleeping on latches, sockets, and postmaster-death notifications.

Fixer flagged `postgres` as a likely busy-poll loop. The concrete collected signal was a postmaster stack in `WaitEventSetWait()` -> `epoll_wait()`, `/proc` state `S (sleeping)`, `wchan=do_epoll_wait`, one captured `epoll_wait` strace line over five seconds, and only `0.7%` total CPU across nine PostgreSQL processes.

The likely root cause is not a PostgreSQL busy loop. The perf samples mostly hit kernel paths such as `clear_page_erms`, while the PostgreSQL frame is the normal Linux wait backend for `ServerLoop()`. I followed the saved plan and did not change course: without evidence of repeated immediate `epoll_wait()` returns, adding throttling or alternate control flow would be speculative and could delay connection accepts, shutdown/reload handling, or child-exit processing.

I reviewed the prior Fixer patch and rejected it rather than improving it: it consists of generated build artifacts such as `GNUmakefile`, `objfiles.txt`, and generated parser files, and it does not address the observed wait path. Relevant local conventions checked were `WaitEventSet`, `AddWaitEventToSet()`, `WaitEventSetWait()`, latch handling, `pgstat_report_wait_*`, `ereport()`/`elog()`, and fd accounting helpers such as `AcquireExternalFD()`/`ReleaseExternalFD()`. The expected effect is that no upstream diff is proposed until stronger evidence shows a real postmaster wait-loop defect.

No source files were changed. The collected signal points at a Python-hosted `supervisord` application loop, not a demonstrated CPython runtime defect, so an upstream CPython patch would be speculative.

The collected perf, `strace`, and `/proc` evidence shows a `supervisord` process run by Python. The trace repeats `wait4(-1, ..., WNOHANG) = ECHILD` followed by `poll(..., 1000) = 0`, while `/proc` reports the process sleeping in `poll_schedule_timeout`. That is consistent with an application event loop waking once per second to check child status and fd readiness, not with a tight CPython busy loop.

The likely code-level cause is outside this source tree: `supervisord` is polling one fd and checking for child processes even when no child is available. I inspected the relevant CPython runtime paths anyway. `Modules/selectmodule.c` already releases the GIL around `poll()`, retries on `EINTR`, and recomputes timeouts with `_PyDeadline`; `Modules/posixmodule.c` uses `Py_BEGIN_ALLOW_THREADS` and `PyErr_CheckSignals()` around `wait4()`; `Lib/selectors.py` and `Lib/subprocess.py` follow their existing timeout and wait-lock conventions.

I followed the saved plan and did not make a source change. The prior Fixer diff should be superseded because it adds generated `Makefile.pre` output while its own explanation says no source patch is justified. The expected effect is no CPython behavior change, avoiding an unsafe runtime patch based only on indirect profiler and syscall evidence.

No upstream source change was made. The collected evidence points to the postmaster blocked in PostgreSQL's normal wait-set path, not to a proven busy loop. Adding a delay or changing `WaitEventSetWait()` from this evidence would risk regressions in connection acceptance, signal handling, and background-worker startup.

Fixer observed a postmaster backtrace in `WaitEventSetWait()` and `epoll_wait()`, with perf samples including kernel page-cache symbols such as `next_uptodate_folio`. The same evidence also shows the process state as sleeping, `wchan` as `do_epoll_wait`, and only one `epoll_wait` line captured over a five-second strace window.

The likely root cause is therefore a false-positive “busy-poll” classification of the postmaster’s normal idle wait path. In PostgreSQL, the postmaster uses a wait set, meaning a reusable abstraction around kernel readiness APIs such as epoll plus latches for signal wakeups. `ServerLoop()` calls `DetermineSleepTime()` and then blocks in `WaitEventSetWait()`; that matches the observed stack.

I followed the plan and did not edit `src/backend/postmaster/postmaster.c` or `src/backend/storage/ipc/waiteventset.c`. Nearby code already uses PostgreSQL helpers and conventions: `WaitEventSetWait()`, `ConfigurePostmasterWaitSet()`, latch helpers, timestamp helpers, `AllocateFile`/`FreeFile`, and `ereport`/`elog`. No safer local helper was missing.

The expected effect is avoiding a speculative upstream patch that could add latency or change shared wait semantics without evidence of a PostgreSQL bug.

Bound the transient accept-retry path in `systemd-userwork` so the worker no longer immediately loops on non-ready listen sockets. When `accept4()` returns `-EAGAIN`/`-EWOULDBLOCK`, the worker now waits briefly for `POLLIN` before retrying, preventing a tight CPU spin without changing normal connection handling or worker shutdown checks.

The perf evidence showed `systemd-userwork` spending all observed CPU in `native_queued_spin_lock_slowpath`, with `accept4` appearing in the syscall profile and a `wchan` of `__skb_wait_for_more_packets`, which is consistent with a userspace accept loop repeatedly spinning on the listening socket instead of blocking/yielding on transient no-op readiness conditions. In `src/userdb/userwork.c`, the prior `-EAGAIN` branch did unconditional `continue`, so a spurious wakeup/no-op path could immediately re-enter `accept4()` and keep contending. The patch changes that exact branch to perform a bounded `fd_wait_for_event(listen_fd, POLLIN, PRESSURE_SLEEP_TIME_USEC)` before retrying, while preserving `-EINTR` continue semantics and existing post-accept connection-pressure signaling. This directly targets the observed runaway-loop pattern with minimal, local behavior change. I followed the plan’s direction for this path and did not apply the optional worker-limit adjustment in `userdbd-manager.h`, since the evidence did not yet show lock contention scaling from worker explosion versus single-worker loop churn.