[PATCH AUTOSEL 6.19-5.10] objtool: Fix Clang jump table detection

[Sasha Levin <sashal@kernel.org>]

From: Josh Poimboeuf <jpoimboe@kernel.org>

[ Upstream commit 4e5019216402ad0b4a84cff457b662d26803f103 ]

With Clang, there can be a conditional forward jump between the load of
the jump table address and the indirect branch.

Fixes the following warning:

  vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame

Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Link: https://patch.msgid.link/7d8600caed08901b6679767488acd639f6df9688.1773071992.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The buggy code (`insn->type == INSN_JUMP_UNCONDITIONAL`) exists in both
6.1 and 6.6 stable. The patch would apply with minor context differences
(the code after the jump table detection differs slightly between
versions).

### Step 6.2: Backport Complications
The code in stable trees has slightly different structure in
`find_jump_table()` (uses `reloc` variable and `insn->jump_table`
instead of `insn->_jump_table`), but the specific code being changed in
`mark_func_jump_tables()` is **identical** across all versions. The
patch should apply cleanly to the `mark_func_jump_tables()` function.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- **Subsystem**: objtool (tools/objtool/) — a build tool for kernel
  stack validation
- **Criticality**: IMPORTANT — objtool is used during every kernel build
  with Clang or CONFIG_OBJTOOL enabled. Incorrect objtool analysis can
  produce spurious warnings that become errors with CONFIG_WERROR, and
  can also miss real issues.
- **Author**: Josh Poimboeuf — the **maintainer** of objtool. His fixes
  carry maximum weight for this subsystem.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is Affected
Anyone building the kernel with **Clang** compiler where Clang generates
conditional forward jumps in switch tables. This affects the BPF
subsystem (`___bpf_prog_run`) specifically mentioned, but potentially
other functions too.

### Step 8.2: Trigger Conditions
- Building the kernel with Clang (increasingly common, required by
  Android)
- Having BPF enabled (very common)
- The warning appears during every build — not intermittent

### Step 8.3: Failure Mode Severity
- **Build warnings** that become **build failures** with
  `CONFIG_WERROR=y`
- **Incorrect stack validation** — objtool may miss real stack issues
- Severity: **MEDIUM-HIGH** — build breakage for Clang users,
  correctness issue for stack validation

### Step 8.4: Risk-Benefit
- **BENEFIT**: High — fixes build warnings/errors for Clang users,
  improves objtool correctness
- **RISK**: Very low — the change removes 2 conditions from an `if`
  statement, making it more inclusive. This is authored by the objtool
  maintainer. The worst case of being too inclusive would be extra back-
  pointers, which is benign.
- **Ratio**: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real build warning that becomes a build failure with
  CONFIG_WERROR
- Fixes incorrect objtool analysis (correctness bug)
- Reported by Arnd Bergmann (prominent developer), affecting Clang
  builds
- Very small, surgical fix (removes 2 conditions from one `if`
  statement)
- Authored by the objtool maintainer (Josh Poimboeuf)
- Merged via objtool/urgent track
- Buggy code exists identically in all stable trees (introduced 2018)
- Patch applies cleanly to the specific code being changed
- Self-contained (patches 2/3 and 3/3 in the series are for unrelated
  subsystems)

**AGAINST backporting:**
- It's a build tool fix, not a runtime kernel bug
- No explicit stable nomination
- 240 changes to objtool/check.c since 6.1 means context may have
  diverged elsewhere

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — authored by maintainer,
   removes overly restrictive condition, tested by reporter
2. **Fixes a real bug?** YES — false warnings/build failures with Clang
3. **Important issue?** YES — build failures affect all Clang users,
   objtool correctness matters
4. **Small and contained?** YES — ~5 lines changed in one function
5. **No new features or APIs?** CORRECT — no new features
6. **Can apply to stable?** YES — the specific code being changed is
   identical in stable

### Step 9.3: Exception Categories
Not an exception category — this is a straightforward bug fix.

### Step 9.4: Decision

This is a small, obviously correct fix by the objtool maintainer that
addresses real build warnings/failures for Clang users. The buggy code
is present in all stable trees, the fix is surgical, and the risk is
minimal. Build tool fixes are important for stable because users need to
be able to compile their kernels.

## Verification

- [Phase 1] Parsed tags: Reported-by: Arnd Bergmann, Closes: lore link,
  Link: patch link, SOB: Josh Poimboeuf (objtool maintainer)
- [Phase 1] Subject: "Fix" verb, objtool subsystem, Clang jump table
  detection
- [Phase 1] Commit body: describes conditional forward jump between jump
  table load and indirect branch in Clang output
- [Phase 2] Diff: removes `insn->type == INSN_JUMP_UNCONDITIONAL` and
  `insn->offset > last->offset` from one if-statement in
  `mark_func_jump_tables()`, updates comment
- [Phase 3] git blame: buggy code introduced in `99ce7962d52d` (Peter
  Zijlstra, 2018-02-08), present in all stable trees
- [Phase 3] git show 99ce7962d52d: confirmed original commit added the
  overly-restrictive INSN_JUMP_UNCONDITIONAL check
- [Phase 3] Author check: Josh Poimboeuf is the objtool maintainer with
  10+ recent objtool commits
- [Phase 3] Series: This is 1/3 but patches 2 and 3 are unrelated
  subsystems (ASoC, IIO) — standalone
- [Phase 4] Lore: Patch merged via objtool/urgent track, no NAKs or
  concerns
- [Phase 4] Bug report: Arnd Bergmann reported multiple objtool warnings
  with Clang builds
- [Phase 5] Callers: `mark_func_jump_tables()` called from
  `add_jump_table_alts()` during objtool analysis; `first_jump_src` used
  in `find_jump_table()` backward search
- [Phase 6] Verified buggy code exists identically in v6.1 and v6.6
  stable trees — patch applies to the changed lines
- [Phase 6] Related commit ef753d66051ca is another Clang jump table
  fix, but for a different issue (consecutive jump table ordering)
- [Phase 7] Subsystem: objtool, IMPORTANT criticality (build tool used
  by all Clang builds)
- [Phase 8] Trigger: building kernel with Clang + BPF enabled (common);
  Severity: MEDIUM-HIGH (build warning/failure)
- [Phase 8] Risk: very low (2 conditions removed, more inclusive
  matching, authored by maintainer)

**YES**

 tools/objtool/check.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index eba35bb8c0bdf..8687991215d63 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2144,12 +2144,11 @@ static void mark_func_jump_tables(struct objtool_file *file,
 			last = insn;
 
 		/*
-		 * Store back-pointers for unconditional forward jumps such
+		 * Store back-pointers for forward jumps such
 		 * that find_jump_table() can back-track using those and
 		 * avoid some potentially confusing code.
 		 */
-		if (insn->type == INSN_JUMP_UNCONDITIONAL && insn->jump_dest &&
-		    insn->offset > last->offset &&
+		if (insn->jump_dest &&
 		    insn->jump_dest->offset > insn->offset &&
 		    !insn->jump_dest->first_jump_src) {
 
-- 
2.51.0