Runaway CPU investigation for htop: unknown userspace loop at lock_next_vma

Prompt

## Plan Pass

You are planning a fixer patch before any edits happen.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. Inspect the relevant code, but do not edit files in this pass.

Return a short markdown plan with these exact sections:

## Problem
## Proposed Subject
## Patch Plan
## Risks
## Validation

The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, and reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative.

## Patch Pass

You are working on a bounded fixer proposal.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff.

Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report. 

Keep the change narrowly scoped and summarize validation clearly.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why.

## Issue Connection
Explain how the code change addresses the observed issue evidence instead of merely paraphrasing the diff.

## Validation
List the checks you ran, or say clearly that you could not run them.

Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.

## Review Pass 1

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

## Refinement Pass 1

You are refining a fixer patch after an explicit code review.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Read the latest author response at `./patch-output.txt`. Read the review report at `./review-1-output.txt`. This is refinement round 1. The original pre-edit snapshot is available at `./source` if you need to compare the current patch against it. Re-read the planning pass at `./plan-output.txt` before editing. Address the review findings with the smallest reasonable follow-up changes. Keep the patch upstream-friendly, avoid awkward control flow when a simpler structure will do, keep the final response gittable, run relevant tests if available, and summarize which review findings you addressed.

In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:

## Commit Message
A short upstream-friendly explanation of what changed and why.

## Issue Connection
Explain how the code change addresses the observed issue evidence instead of merely paraphrasing the diff.

## Validation
List the checks you ran, or say clearly that you could not run them.

## Review Pass 2

You are reviewing a freshly generated fixer patch.

Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the patch again after the latest refinement. The original pre-edit snapshot is available at `./source` for diffing. The latest author response is at `./refine-1-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change.

Do not apply code changes in this pass.

Return a short markdown review report. The first non-empty line must be exactly one of:

RESULT: ok
RESULT: fix-needed

If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.

Response

Subject: linux: preserve deleted-library flag during LRS-only maps scans

## Commit Message
Preserve `usesDeletedLib` during LRS-only `/proc/<pid>/maps` refreshes and add a separate deleted-library recheck timestamp. This keeps the throttled maps-scan change from clearing a valid deleted-library state during unrelated M_LRS refreshes.

## Issue Connection
Perf evidence for this issue was dominated by `lock_next_vma` and other kernel-side map-walking symbols, which points to repeated `/proc/<pid>/maps` scanning rather than a pure userspace hot loop. The patch separates deleted-library checks from the M_LRS refresh cadence and keeps LRS-only scans from clearing `usesDeletedLib`, so the reduced scan rate no longer regresses stale-library highlighting.

## Validation
- `sh autogen.sh`
- `./configure`
- `make -j2`
- The build completed successfully.
- Interactive perf/runtime validation was not run in this environment.

Diff

--- a/linux/LinuxProcess.h
+++ b/linux/LinuxProcess.h
@@ -107,6 +107,7 @@
    unsigned long ctxt_diff;
    char* secattr;
    unsigned long long int last_mlrs_calctime;
+   unsigned long long int last_deleted_lib_calctime;
 
    /* Total GPU time used in nano seconds */
    unsigned long long int gpu_time;
--- a/linux/LinuxProcessTable.c
+++ b/linux/LinuxProcessTable.c
@@ -724,7 +724,8 @@
 static void LinuxProcessTable_readMaps(LinuxProcess* process, openat_arg_t procFd, const LinuxMachine* host, bool calcSize, bool checkDeletedLib) {
    Process* proc = (Process*)process;
 
-   proc->usesDeletedLib = false;
+   if (checkDeletedLib)
+      proc->usesDeletedLib = false;
 
    FILE* mapsfile = fopenat(procFd, "maps", "r");
    if (!mapsfile)
@@ -1638,19 +1639,42 @@
 
       {
          bool prev = proc->usesDeletedLib;
-
-         if (!proc->isKernelThread && !proc->isUserlandThread &&
-             ((ss->flags & PROCESS_FLAG_LINUX_LRS_FIX) || (settings->highlightDeletedExe && !proc->procExeDeleted && isOlderThan(proc, 10)))) {
-
-            // Check if we really should recalculate the M_LRS value for this process
-            uint64_t passedTimeInMs = host->realtimeMs - lp->last_mlrs_calctime;
-
-            uint64_t recheck = ((uint64_t)rand()) % 2048;
-
-            if (passedTimeInMs > recheck) {
-               lp->last_mlrs_calctime = host->realtimeMs;
-               LinuxProcessTable_readMaps(lp, procFd, lhost, ss->flags & PROCESS_FLAG_LINUX_LRS_FIX, settings->highlightDeletedExe);
+         if (!proc->isKernelThread && !proc->isUserlandThread) {
+            bool checkLrs = false;
+            bool checkDeletedLib = false;
+            const bool checkForDeletedLib = settings->highlightDeletedExe && !proc->procExeDeleted && isOlderThan(proc, 10);
+            const bool checkThisProcessForMaps = (ss->flags & PROCESS_FLAG_LINUX_LRS_FIX) || checkForDeletedLib;
+
+            if (ss->flags & PROCESS_FLAG_LINUX_LRS_FIX) {
+               // Check if we really should recalculate the M_LRS value for this process.
+               uint64_t passedTimeInMs = host->realtimeMs - lp->last_mlrs_calctime;
+               uint64_t recheck = ((uint64_t)rand()) % 2048;
+
+               checkLrs = passedTimeInMs > recheck;
             }
+
+            if (checkForDeletedLib && !proc->usesDeletedLib) {
+               // Check for deleted libraries less frequently than regular M_LRS scans.
+               const uint64_t deletedLibCheckIntervalMs = 10000;
+               uint64_t passedTimeInMs = host->realtimeMs - lp->last_deleted_lib_calctime;
+               uint64_t recheck = ((uint64_t)rand()) % 2048;
+
+               checkDeletedLib = passedTimeInMs > (deletedLibCheckIntervalMs + recheck);
+            }
+
+            if (checkLrs || checkDeletedLib) {
+               if (checkLrs)
+                  lp->last_mlrs_calctime = host->realtimeMs;
+               if (checkDeletedLib)
+                  lp->last_deleted_lib_calctime = host->realtimeMs;
+
+               LinuxProcessTable_readMaps(lp, procFd, lhost, checkLrs, checkDeletedLib);
+            } else if (!settings->highlightDeletedExe || proc->procExeDeleted) {
+               proc->usesDeletedLib = false;
+            } else if (!checkThisProcessForMaps) {
+               lp->m_lrs = 0;
+            }
+
          } else {
             /* Copy from process structure in threads and reset if setting got disabled */
             proc->usesDeletedLib = (proc->isUserlandThread && mainTask) ? mainTask->super.usesDeletedLib : false;