Patch handoffs

When raising a session, focus the session’s tracked active terminal widget directly instead of asking Qt to rediscover the focused child through `QWidget::focusWidget()`. Yakuake already tracks the active terminal for each session, and using that stored terminal widget keeps the intended focus behavior while avoiding a fragile focus-chain lookup during session switching.

Fixer observed a Yakuake SIGSEGV in a coredump from `/usr/bin/yakuake`; the stack entered `QWidget::focusWidget()` while Qt was processing focus events. I did not independently reproduce that crash.

The cautious code-level connection is that `SessionStack::raiseSession()` used `session->widget()->focusWidget()` immediately after changing the current stacked widget. The focus chain is Qt’s record of which child widget currently owns focus inside a parent widget. In this path Yakuake does not need Qt to rediscover that child: the `Session` already records its active `Terminal`, and `Terminal::terminalWidget()` is a guarded pointer to the embedded terminal widget.

The patch changes `raiseSession()` to fetch the active terminal via `session->getTerminal(session->activeTerminalId())` and focus that terminal widget if it still exists. This addresses the review finding by avoiding the `focusWidget()` call entirely in this path, rather than just reducing duplicate calls. The expected effect is to preserve session-raise focus behavior while avoiding the crash-adjacent Qt focus-chain lookup.

`polygonize_noded_linked_polygon` builds a noded boundary graph, meaning boundary segments are split wherever they cross before faces are rebuilt. The graph builder compared every segment pair with full intersection math, even when their latitude/longitude ranges could not overlap.

Cache conservative bounds on each `NodedSegment` and skip impossible segment pairs before the existing intersection and collinear-overlap checks. This follows the saved plan, the local PostgreSQL allocation conventions (`palloc`/`pfree`) and H3 `VertexGraph` helper flow, and is intended for upstream `main` rather than a Debian-local workaround.

Fixer observed a perf trace where `postgres` spent 5.85% of sampled CPU in `h3_postgis.so` under `polygonize_noded_linked_polygon`. This was observed by Fixer and not independently reproduced; the evidence is profiler-only, with no SQL reproducer or user-visible failure.

The cautious code-level inference is that the noded polygonizer can spend avoidable time in its all-pairs segment loop. Before this patch, `graph_add_noded_linked_polygon_edges()` called the detailed crossing and collinear-overlap routines for every pair of boundary segments, including pairs whose bounding boxes are disjoint.

The change adds cached min/max latitude and longitude bounds to each `NodedSegment`, plus a conservative `segments_bounds_overlap()` guard before the detailed pair checks. I added a short comment documenting the invariant: the reject must remain conservative because missed overlaps would drop graph nodes.

The expected effect is to reduce CPU spent in the observed polygonizer path for large split-boundary inputs while preserving the existing topology behavior for any segment pair that could actually overlap.

Change the normal SMTP server command reader so an overlong command is rejected and the session is closed instead of draining all excess input first. The command path still uses Postfix’s `smtp_get()` and `VSTREAM` helpers. SASL continuation reads keep the old drain behavior because those are caller-bounded and recoverable within AUTH.

Fixer observed `smtpd` in `smtp_get()` through `vstring_get_flags_bound()` and `timed_read()`, with samples in `gettimeofday()` and kernel allocation paths. The likely root cause is that `smtpd_chat_query()` currently expands to `smtpd_chat_query_limit(..., var_line_limit)`, and that helper uses `SMTP_GET_FLAG_SKIP`, which keeps reading until newline after the command has already exceeded `line_length_limit`.

I reproduced the bounded helper-level failure signal with a temporary program linked against Postfix’s own libraries: `smtp_get_noexcept(..., SMTP_GET_FLAG_NONE)` returned immediately after the bound, while `smtp_get_noexcept(..., SMTP_GET_FLAG_SKIP)` timed out waiting for newline on an open pipe. That matches the collected stack’s read path.

The patch replaces the macro with an `int smtpd_chat_query()` that does not use `SMTP_GET_FLAG_SKIP`. The main SMTP command loop now treats a false return as a protocol error, replies `500 5.5.2 Error: command line too long`, and breaks the session. `smtpd_chat_query_limit()` still drains excess input for SASL continuation lines.

Security impact analysis: this is a resource-use hardening change for malformed SMTP input. It does not change authentication success/failure semantics, credential handling, authorization decisions, cryptography, sandboxing, or permissions. The expected effect is to bound work for overlong SMTP commands and disconnect instead of continuing to read client-controlled excess input.

`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.

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`.

`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.

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.

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.

`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.

`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.

`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.

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.

`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.

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.

`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()`.

`supervisord` no longer asks the kernel for exited children on every idle main-loop pass when it has no tracked child PIDs and has not received `SIGCHLD`, the child-exit signal. The loop now handles any pending signal first and only calls the existing `options.waitpid()` wrapper when Supervisor is tracking children or when `SIGCHLD` indicates a child may need reaping.

Fixer observed `/usr/bin/python3 /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf` alternating one-second `poll()` timeouts with `wait4(-1, WNOHANG) = -1 ECHILD`, meaning the process was asking for exited children when the kernel reported that there were none. This was observed by Fixer and not independently reproduced as a syscall trace because ptrace/`strace` is blocked in this sandbox.

The hot process was Python, but the evidence identified the script entrypoint as `supervisord`, so the patch targets Supervisor application logic rather than the Python runtime. In `Supervisor.runforever()`, the code previously called `self.reap()` unconditionally after every poll; `reap()` uses Supervisor’s local `options.waitpid()` helper. The patch makes `handle_signal()` return the signal it consumed, and `runforever()` only reaps when `options.pidhistory` has tracked child PIDs or that signal is `SIGCHLD`.

The expected effect is to remove the unnecessary idle `waitpid` path when there are no known children to reap, while preserving normal cleanup for Supervisor-managed children and unknown children announced by `SIGCHLD`. I checked `README.rst`, `docs/development.rst`, `tox.ini`, and the touched subsystem; the relevant local helpers are `options.waitpid()`, `options.get_signal()`/`SignalReceiver`, and `options.poller`, and the patch keeps using them. Review round 1 only flagged EOF whitespace churn in `supervisor/tests/test_supervisord.py`; that incidental diff has been removed.

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.

Supervisor’s main loop reaped children on every idle tick. Reaping uses `waitpid`, the POSIX call that checks for exited child processes, so idle configurations could repeatedly ask the kernel for child status even when Supervisor had no child PID to track. Only run the periodic reap when Supervisor has tracked child PIDs or has received `SIGCHLD`, the child-exited signal.

Fixer observed a `supervisord` Python entrypoint with high CPU attribution, a sleeping process in `poll_schedule_timeout`, and a trace alternating between `poll(..., 1000)` and `wait4(-1, ..., WNOHANG) = -1 ECHILD`; `ECHILD` means the kernel had no child process status to return. The failure signal was observed by Fixer and not independently reproduced as a CPU runaway.

The cautious code-level inference is that `Supervisor.runforever()` called `self.reap()` after every poll cycle. `reap()` correctly goes through Supervisor’s local `ServerOptions.waitpid()` wrapper, but doing that while `pidhistory` is empty causes the no-child `wait4` path seen in the trace.

The change keeps the local wrappers and main-loop conventions: it reads the pending signal once through `options.get_signal()`, reaps only when `pidhistory` has tracked child PIDs or the pending signal is `SIGCHLD`, and passes that already-read signal into `handle_signal()`. I kept the prior Fixer patch’s useful direction, including the private sentinel that prevents `handle_signal(None)` from reading the signal queue a second time, and added a short comment explaining why `SIGCHLD` still reaps with empty `pidhistory`.

The expected effect is to remove unnecessary idle `waitpid`/`wait4` calls without suppressing normal managed-child or unknown-child cleanup.

Avoid an unnecessary idle `waitpid()` call in `supervisord` when there are no tracked child processes. Reaping means collecting an exited child process status with `waitpid()`. Supervisor records managed child PIDs in `options.pidhistory` when they are forked, so the periodic idle loop can skip reaping when that map is empty.

When `SIGCHLD`, the child-exit signal, is received, `supervisord` still forces one reap attempt so unknown children can be collected and logged.

Fixer observed `/usr/bin/python3 /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf` repeatedly doing `wait4(-1, ..., WNOHANG) = -1 ECHILD` followed by a one-second `poll()` timeout. This failure was observed by Fixer and not independently reproduced as the full daemon/perf trace in this sandbox because `strace` is blocked by ptrace restrictions.

The code-level cause is that `Supervisor.runforever()` calls `reap()` every loop, and `reap()` called Supervisor’s local `Options.waitpid()` wrapper even when `options.pidhistory` had no managed child PIDs. A bounded local harness confirmed the targeted call path: the original source called real `os.waitpid(-1, os.WNOHANG)` with empty `pidhistory` and received `ECHILD`; the patched source made zero calls on the same idle path.

The patch makes ordinary idle `reap()` return before calling `waitpid()` when no managed child PID is tracked. To avoid dropping unknown-child cleanup, `SIGCHLD` handling calls `reap(force=True)`, and recursive reaping keeps draining after one child status is returned. I followed existing local conventions: `options.pidhistory`, `Supervisor.reap()`, `Options.waitpid()`, `SignalReceiver`, and `options.logger`.

The expected effect is that idle supervisord stops making pointless once-per-second nonblocking `waitpid()` calls that can only return `ECHILD`, while preserving child collection when a child-exit signal indicates there may be a status to reap. The short comments document the `pidhistory` invariant and the forced recursive drain case.

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.

After a failed authentication request, `sshd-auth` enforces a delay before sending failure. Make that delay wake when the client connection is closed, while preserving the delay for live clients.

Fixer observed `sshd-auth` sleeping in `clock_nanosleep`, then writing to the client fd, polling it, and finally seeing `ECONNRESET`. `/proc` showed the process was sleeping with low CPU, so the likely root cause is delayed cleanup after the peer disconnects during the authentication failure delay, not a reproduced CPU runaway. This failure was observed by Fixer and not independently reproduced.

The code-level cause is that `ensure_minimum_time_since()` used unconditional `nanosleep()`, so a preauth child could wait out the whole delay before discovering that the client had already gone away. I changed it to wait with `ppoll()` on `ssh_packet_get_connection_in(ssh)`, request `POLLIN` for portable `ppoll()` compatibility, and use `recv(..., MSG_PEEK)` to distinguish EOF from queued data without consuming SSH packet input. The expected effect is that a peer close during the auth failure delay returns through the existing dispatch error path instead of waiting and then writing to a reset socket.

Review findings addressed: the patch no longer relies on unsupported compat `POLLHUP`/`POLLERR` reporting with no requested events, and `make tests` was run and its environment blocker is reported. I also kept the short comment explaining the `POLLIN` plus peek invariant.

Local conventions checked: `README.md` documents `./configure && make tests`; nearby code uses `ppoll()`, `monotime_double()`, `ssh_packet_get_connection_in()`, `debug3_f()`, and `SSH_ERR_*`. `misc.c` has `waitrfd()` and `ptimeout` helpers, but `waitrfd()` would spin on already queued live-client input here, so the local bounded loop is used instead.

Use pidfd polling for POSIX `Popen.wait(timeout=...)` when available, and keep very large or infinite Python timeouts compatible by clamping each `poll()` call while continuing to recompute the Python deadline.

The user-visible symptom was a `python3.13` process repeatedly waking in `poll` and `wait4`, with CPU samples in Python frame evaluation. A plausible code-level cause is the POSIX `subprocess.Popen._wait(timeout)` loop, which uses repeated nonblocking `waitpid(..., WNOHANG)` calls with short sleeps.

The patch adds a Linux pidfd-backed wait path for timeout waits. This refinement addresses the review finding by treating an empty result from a clamped `poll()` as one elapsed kernel-sized wait, then continuing the loop while the Python timeout still has time remaining. The regression test now covers the case where the first clamped poll returns no events and a later poll observes process exit.

The expected effect is fewer avoidable userspace wakeups for normal timeout waits on Linux with pidfds, while preserving behavior for very large and infinite timeouts. The code includes short comments for the non-obvious timeout clamping and pidfd/readiness remapping logic.

Keep Plasma's public layout order aligned with the order saved in its keyboard settings, and remember the previous layout before rebuilding the live layout list for Spare Layouts.

Plasma stores three layouts here, but only two should stay in the normal switching cycle while the third remains spare. The bug was that Plasma leaked its temporary live reordering back into the layout list and indices seen by the applet and shortcuts, so selecting a spare layout could confuse direct selection. This patch keeps the public order in the configured order while letting the internal live switcher keep doing its temporary spare-layout swap. It also remembers the previous layout before rebuilding the live list, so the 'last used layout' action still returns to the layout the user actually came from.

Reduce wakeup churn in the POSIX `Popen._wait(timeout=...)` path by keeping a bounded, monotonically increasing poll delay and checking completion in a single explicit loop condition. This lowers the number of `waitpid`/sleep wakeups under timeouts while preserving `TimeoutExpired` behavior and lock-based returncode handoff semantics. A focused regression test was added to validate that the timeout path uses backoff progression instead of immediate repeated checks.

The evidence shows a user-space timed loop pattern (`poll`/`wait4` alternating, `wchan=poll_schedule_timeout`, `__vdso_clock_gettime` hot) consistent with a high-frequency poll-and-sleep wait strategy rather than efficient blocking waits. In CPython’s `_wait` implementation this is exactly the `timeout` branch that loops with `waitpid(WNOHANG)` and short sleeps, which had been labeled a “busy loop” in-source. The patch tightens that exact branch: it keeps the same deadline calculation and lock gate, but moves the flow into a single `while self.returncode is None` loop with an explicit timeout check and exponential backoff capped by both the remaining timeout and 50 ms. This directly reduces repeated short wakeups that match the perf signature and keeps the process from cycling too quickly.

The added test verifies that the timed loop performs two increasingly spaced sleeps (`0.001` then `0.002`) before handling a terminal `waitpid` result, confirming the new behavior is bounded and backoff-driven without introducing timing flakiness.

MODULE_PATHNAME expands to "$libdir/foo" without DLSUFFIX. Prefer the suffixed shared library name first to avoid a guaranteed failed probe for the unsuffixed name, but preserve compatibility by falling back to the existing lookup path if the suffixed file is not present.

Fixer observed file not found retry loop. This patch updates src/backend/utils/fmgr/dfmgr.c so mODULE_PATHNAME expands to "$libdir/foo" without DLSUFFIX. Prefer the suffixed shared library name first to avoid a guaranteed failed probe for the unsuffixed name, but preserve compatibility by falling back to the existing lookup path if the suffixed file is not present.