BPF List
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>,
	Andrii Nakryiko <andrii@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	ast@kernel.org, daniel@iogearbox.net, eddyz87@gmail.com,
	memxor@gmail.com, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.1] libbpf: Add __NR_bpf definition for LoongArch
Date: Mon, 31 Aug 2026 09:23:46 -0400	[thread overview]
Message-ID: <20260831133314.4125787-198-sashal@kernel.org> (raw)
In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org>

From: Tiezhu Yang <yangtiezhu@loongson.cn>

[ Upstream commit a4a5d4ee061240a1d39053db0a87f841d43277c0 ]

LoongArch uses the generic syscall table, where __NR_bpf is defined
as 280 in include/uapi/asm-generic/unistd.h.

To align with other architectures, add the __NR_bpf definition for
LoongArch to avoid a potential compilation failure: "error __NR_bpf
not defined. libbpf does not support your arch."

This is a follow up patch of:

  commit b0c47807d31d ("bpf: Add sparc support to tools and samples.")
  commit bad1926dd2f6 ("bpf, s390: fix build for libbpf and selftest suite")
  commit ca31ca8247e2 ("tools/bpf: fix perf build error with uClibc (seen on ARC)")
  commit e32cb12ff52a ("bpf, mips: Fix build errors about __NR_bpf undeclared")

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260526063936.16769-1-yangtiezhu@loongson.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `libbpf: Add __NR_bpf definition for
LoongArch`

**Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`,
`make kernelversion` → `6.18.44`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[libbpf] [add] [__NR_bpf definition for LoongArch]`

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Tiezhu Yang `<yangtiezhu@loongson.cn>` (author)
- **Signed-off-by:** Andrii Nakryiko `<andrii@kernel.org>` (libbpf
  maintainer)
- **Link:** https://lore.kernel.org/bpf/20260526063936.16769-1-
  yangtiezhu@loongson.cn
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable tags
- Notable: maintainer Signed-off-by is a quality signal; no syzbot/user
  bug report

### Step 1.3: Body analysis
**Record:**
- **Bug:** When building libbpf/bpf tools on LoongArch with overridden
  `unistd.h` (perf build path), `__NR_bpf` is undefined and compilation
  fails with `#error __NR_bpf not defined. libbpf does not support your
  arch.`
- **Symptom:** Build failure (compile-time `#error`), not a runtime
  kernel crash
- **Root cause:** LoongArch uses the generic syscall table (`__NR_bpf` =
  280 in `asm-generic/unistd.h`), but the explicit arch fallback list in
  `tools/lib/bpf/bpf.c` and `tools/build/feature/test-bpf.c` was never
  updated for `__loongarch__`
- **Version info:** None in message; follow-up to arch-specific
  `__NR_bpf` additions dating from 2017–2021

### Step 1.4: Hidden bug fix?
**Record:** Yes — described as alignment/cleanup, but it is a **build
fix** preventing compilation failure on LoongArch, same class as prior
mips/ARC/s390/sparc fixes by the same pattern.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- `tools/lib/bpf/bpf.c`: +2 lines
- `tools/build/feature/test-bpf.c`: +2 lines
- **Total:** 4 insertions, 0 deletions
- **Functions affected:** None directly; modifies preprocessor fallback
  block before `sys_bpf()` / `main()`
- **Scope:** Single-purpose, two-file surgical fix

### Step 2.2: Code flow change
**Record:**
- **Hunk 1 (`bpf.c`):** Before → `#elif mips` then `#else #error`. After
  → adds `#elif defined(__loongarch__) #define __NR_bpf 280` before the
  error branch. Affects the `#ifndef __NR_bpf` fallback used when perf
  overrides `unistd.h`.
- **Hunk 2 (`test-bpf.c`):** Same preprocessor addition for bpf feature-
  detection compile test.

### Step 2.3: Bug mechanism
**Record:** **Build fix / missing arch definition (category
h-adjacent).** When `__NR_bpf` is not provided by headers (overridden
`unistd.h` path documented in `bpf.c`), LoongArch hits the `#else
#error` branch. Fix supplies the correct syscall number (280).

### Step 2.4: Fix quality
**Record:** Obviously correct — value 280 matches `include/uapi/asm-
generic/unistd.h` and `tools/arch/loongarch/include/uapi/asm/unistd.h`
(which includes `asm-generic/unistd.h`). Minimal, mirrors existing arch
entries (aarch64, arc also use 280). **Regression risk:** very low; only
affects preprocessor path when `__NR_bpf` is absent.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** `__NR_bpf` fallback block in `bpf.c` introduced in
e3ed2fef22b6 (2015). Arch entries added incrementally: sparc (b0c47807,
2017), s390 (bad1926dd, 2017), arc (ca31ca82, 2019), mips (e32cb12ff,
2021, same author). LoongArch omission is a long-standing gap, not a
recently introduced regression.

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag. Referenced prerequisite commits all
exist in this tree (`b0c47807`, `bad1926dd`, `ca31ca82`, `e32cb12ff`
confirmed via `git merge-base --is-ancestor`).

### Step 3.3: File history
**Record:** Related LoongArch libbpf work already in tree:
`00883922ab404` (bpf_tracing.h), `29c66ad1c3ad1` (PT_REGS_CAST for
LoongArch). `seccomp_bpf.c` already defines `__NR_seccomp` for
`__loongarch__` (line 147). Standalone patch; not part of a multi-patch
series.

### Step 3.4: Author context
**Record:** Tiezhu Yang (Loongson) — prior `e32cb12ff52a2` mips
`__NR_bpf` fix in same files. Andrii Nakryiko (libbpf maintainer)
Signed-off-by.

### Step 3.5: Dependencies
**Record:** No hard dependencies beyond the existing `__NR_bpf` fallback
mechanism (present since 2015+). Applies standalone. Commit itself is
**not** in current branch (`git log --grep` returned empty).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:** `b4 am 20260526063936.16769-1-yangtiezhu@loongson.cn` found
thread at
https://patch.msgid.link/20260526063936.16769-1-yangtiezhu@loongson.cn.
Mbox contains only the patch (1 message, no replies). No stable
nominations or NAKs found. `b4 dig -c HEAD` failed (commit not in tree);
used message-id lookup instead.

### Step 4.2: Reviewers
**Record:** Andrii Nakryiko Signed-off-by on patch. No separate
Reviewed-by in mbox.

### Step 4.3: Bug report
**Record:** N/A — no external bug report or syzbot link. Author
documents expected compile error text.

### Step 4.4: Related patches
**Record:** Part of ongoing arch-by-arch `__NR_bpf` fallback additions.
Same author fixed mips identically in 2021. LoongArch bpf_tracing
support already merged separately.

### Step 4.5: Stable list history
**Record:** Not searched on lore stable list (WebFetch blocked by bot
protection). No stable discussion found in mbox.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** Preprocessor block only. Downstream: `sys_bpf()` in `bpf.c`
calls `syscall(__NR_bpf, ...)`. `test-bpf.c` `main()` calls
`syscall(__NR_bpf, BPF_PROG_LOAD, ...)`.

### Step 5.2: Callers
**Record:** `sys_bpf()` is the central libbpf syscall wrapper — used
throughout libbpf for all BPF operations. Only reached at runtime if
compilation succeeds; this patch affects **compile-time** availability
of `__NR_bpf`.

### Step 5.3: Callees
**Record:** `syscall(__NR_bpf, ...)` — requires correct arch syscall
number.

### Step 5.4: Reachability
**Record:** Triggered when building bpf tools (libbpf, perf, bpftool,
bpf selftests feature detection) on LoongArch hosts where `__NR_bpf` is
not defined by included headers. Userspace build path, not kernel
runtime.

### Step 5.5: Similar patterns
**Record:** `seccomp_bpf.c` already has `__loongarch__` syscall
fallbacks (`__NR_seccomp 277`). `bpf.c` and `test-bpf.c` are
inconsistent — LoongArch was missed. Same pattern fixed for mips, arc,
s390, sparc.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy code exists?
**Record:** **YES.** Current `tools/lib/bpf/bpf.c` lines 43–64 and
`tools/build/feature/test-bpf.c` lines 6–25 lack `__loongarch__` case
and fall through to `#error`. LoongArch arch support present since
`fa96b57c14906` (LoongArch build infrastructure). Bug has existed since
LoongArch tooling support without this define.

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** Two identical 2-line hunks in
files that match the patch context. No conflicting recent churn in this
specific block.

### Step 6.3: Related fixes already present?
**Record:** No equivalent fix found. `git log --grep="Add __NR_bpf
definition for LoongArch"` returns empty on this branch.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
**Record:** **tools/lib/bpf** (userspace libbpf shipped with kernel
sources). **Criticality:** IMPORTANT for bpf tooling; PERIPHERAL for
general kernel runtime (does not affect running kernel on non-LoongArch
or pre-built distros).

### Step 7.2: Activity
**Record:** LoongArch and libbpf actively maintained in 6.18.y (recent
LoongArch BPF/kprobes fixes; ongoing libbpf API work).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** LoongArch users building kernel bpf tools from source
(libbpf, perf, bpftool, bpf feature tests). Not universal; platform-
specific build issue.

### Step 8.2: Trigger conditions
**Record:** Compile libbpf/bpf tools on LoongArch when `__NR_bpf` is not
provided by headers (documented perf override path). Common for
developers/maintainers building from kernel tree on LoongArch hardware.
Unprivileged users can trigger only insofar as they can invoke a build.

### Step 8.3: Failure mode severity
**Record:** **Compile-time failure** (`#error` / undeclared `__NR_bpf`).
**Severity: MEDIUM** for affected users (cannot build tools); **LOW**
for general kernel stability (no runtime crash, corruption, or security
issue).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Enables bpf tool builds on LoongArch; closes obvious gap
  vs. other arches and vs. `seccomp_bpf.c` on same platform
- **Risk:** Very low — 4 lines, correct constant, no logic change
- **Ratio:** Favorable; classic stable build-fix backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real build failure on LoongArch (documented error path)
- Build fix — explicit stable exception category
- Tiny (4 lines), obviously correct (`__NR_bpf` = 280 verified in tree
  headers)
- Same pattern as mips/ARC/s390 fixes already in 6.18.44
- libbpf maintainer Signed-off-by
- Buggy code confirmed present in 6.18.44
- Prerequisites all in tree; standalone apply

**AGAINST backport:**
- No runtime kernel bug (tools-only build issue)
- Affects niche platform (LoongArch)
- No user bug reports or syzbot evidence
- No explicit stable nomination in review thread (thread had no replies)

**Unresolved:** Whether distro packagers always hit the
overridden-`unistd.h` path; author says "potential" failure, but
mechanism is well-established from `bpf.c` comment and prior arch fixes.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — syscall number matches `asm-
   generic/unistd.h`; maintainer SOB; mirrors proven prior arch fixes
2. Fixes real bug affecting users? **PASS** — compile failure for
   LoongArch bpf tool builds
3. Important issue? **PASS (moderate)** — build fix for platform
   developers; not crash/security, but stable explicitly accepts build
   fixes
4. Small and contained? **PASS** — 4 lines, 2 files
5. No new features/APIs? **PASS** — preprocessor define only
6. Can apply to local tree? **PASS** — buggy code present, clean apply
   expected

### Step 9.3: Exception category
**Record:** **BUILD FIX** — prevents compilation failure when building
libbpf/bpf tools on LoongArch.

### Step 9.4: Decision rationale
For Linux **6.18.44**, LoongArch is a supported architecture and bpf
tooling is actively used, but `tools/lib/bpf/bpf.c` and
`tools/build/feature/test-bpf.c` still lack the `__loongarch__` entry in
the `__NR_bpf` fallback table. This is the same class of fix as the mips
(`e32cb12ff52a2`) and ARC (`ca31ca8247e2`) commits already in this tree.
The fix is trivial, correct, and low-risk. While severity is build-time
rather than runtime, stable trees routinely accept such arch-specific
build fixes — especially when they unblock tool compilation on a
supported platform.

---

## Verification

- **[Phase 1]** `git describe HEAD` → v6.18.44; parsed subject, tags,
  body from user-provided commit and mbox
- **[Phase 2]** Read `tools/lib/bpf/bpf.c` lines 39–65; read
  `tools/build/feature/test-bpf.c` full file; confirmed 4-line diff,
  preprocessor-only change
- **[Phase 3]** `git blame -L 43,65 tools/lib/bpf/bpf.c` — fallback
  block history traced to 2015; mips fix e32cb12ff52a2 by same author
- **[Phase 3]** `git merge-base --is-ancestor b0c47807d31d HEAD` →
  prerequisite in tree
- **[Phase 3]** `git log --grep="Add __NR_bpf definition for LoongArch"`
  → not in branch
- **[Phase 3]** `git log --author="Tiezhu Yang" -- tools/lib/bpf/` →
  mips fix + bpf_tracing LoongArch work present
- **[Phase 4]** `b4 am 20260526063936.16769-1-yangtiezhu@loongson.cn` →
  patch retrieved; 1 message, no replies
- **[Phase 4]** WebFetch lore.kernel.org → blocked (bot protection);
  used b4 mbox instead
- **[Phase 5]** `grep __loongarch__ tools/` — found in seccomp_bpf.c,
  bpf_tracing.h, etc., but NOT in bpf.c `__NR_bpf` block
- **[Phase 5]** Read `seccomp_bpf.c` lines 134–164 — `__NR_seccomp` for
  `__loongarch__` already defined
- **[Phase 6]** `grep __NR_bpf tools/lib/bpf/bpf.c` — no `__loongarch__`
  branch in 6.18.44
- **[Phase 6]** `include/uapi/asm-generic/unistd.h` line 677 → `#define
  __NR_bpf 280`
- **[Phase 6]** `tools/arch/loongarch/include/uapi/asm/unistd.h` →
  includes `asm-generic/unistd.h`
- **[Phase 6]** `arch/loongarch/` exists; `git log --reverse --
  arch/loongarch/ | head -1` → fa96b57c14906
- **[Phase 7]** `git log -20 -- arch/loongarch/` — active LoongArch
  development including BPF fixes
- **[Phase 8]** Assessed as build-time failure, platform-specific, low
  runtime risk

**YES**The background search finished. It confirmed that **"libbpf: Add
__NR_bpf definition for LoongArch" is not in the current 6.18.44
branch** — related LoongArch libbpf work is already there
(`bpf_tracing.h`, `PT_REGS_CAST`), but the `__NR_bpf` fallback in
`bpf.c` and `test-bpf.c` is still missing.

That matches the earlier analysis: this is a small, low-risk build fix
for LoongArch bpf tool compilation and should be backported to this
tree.

**YES**

 tools/build/feature/test-bpf.c | 2 ++
 tools/lib/bpf/bpf.c            | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/build/feature/test-bpf.c b/tools/build/feature/test-bpf.c
index e7a405f83af6e..89d59674f39b9 100644
--- a/tools/build/feature/test-bpf.c
+++ b/tools/build/feature/test-bpf.c
@@ -20,6 +20,8 @@
 #  define __NR_bpf 6319
 # elif defined(__mips__) && defined(_ABI64)
 #  define __NR_bpf 5315
+# elif defined(__loongarch__)
+#  define __NR_bpf 280
 # else
 #  error __NR_bpf not defined. libbpf does not support your arch.
 # endif
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 339b197972374..1e8f01bfc1bfd 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -59,6 +59,8 @@
 #  define __NR_bpf 6319
 # elif defined(__mips__) && defined(_ABI64)
 #  define __NR_bpf 5315
+# elif defined(__loongarch__)
+#  define __NR_bpf 280
 # else
 #  error __NR_bpf not defined. libbpf does not support your arch.
 # endif
-- 
2.53.0


  parent reply	other threads:[~2026-08-31 13:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260831133314.4125787-1-sashal@kernel.org>
2026-08-31 13:21 ` [PATCH AUTOSEL 6.18-5.15] libbpf: Also reset {insn,data}_cur on realloc failure Sasha Levin
2026-08-31 14:03   ` sashiko-bot
2026-08-31 13:23 ` Sasha Levin [this message]
2026-08-31 13:27 ` [PATCH AUTOSEL 6.18-6.12] bpftool: Pass host flags to bootstrap libbpf Sasha Levin
2026-08-31 13:29 ` [PATCH AUTOSEL 6.18] bpf, sockmap: reject a packet-modifying SK_SKB stream parser Sasha Levin
2026-08-31 13:29 ` [PATCH AUTOSEL 6.18-5.10] bpf: NUL-terminate replaced sysctl value Sasha Levin
2026-08-31 17:12   ` sashiko-bot
2026-08-31 13:30 ` [PATCH AUTOSEL 6.18] selftests/bpf: Avoid static LLVM linking for cross builds Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260831133314.4125787-198-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=memxor@gmail.com \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=yangtiezhu@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox