repository·main·Indexed 20 days ago
https://github.com/sashiko-dev/sashikoSashiko is an agentic code review system for the Linux kernel (version 0.2.5) that automates patch reviews using a multi-stage protocol. It supports monitoring mailing lists, GitHub, and GitLab, and provides a daemon mode with a Web UI and API. The system integrates with various LLM providers including Gemini, Claude, AWS Bedrock, and Vertex AI, and includes specialized review prompts and skills for the Linux kernel and iproute2.
The review-pr skill is designed to perform scrutinizing code reviews against project standards (such as GEMINI.md) and design documents. It automatically detects relevant design files, categorizes findings by severity, and generates actionable diffs.
When to use: Use this skill when you need to review a Pull Request (PR), a specific diff, or particular components of a codebase.
The NFSD (fs/nfsd/) implements the Linux NFS server for versions v2, v3, and v4.x. The subsystem is composed of several key components including the XDR codec, stateid/delegation state machines, file handle validation, client lifecycle management, callbacks, and session slots.
| Files | Domain |
|---|---|
nfs4xdr.c, nfs3xdr.c | XDR codec, page encoding |
nfs4state.c, nfs4proc.c | NFSv4 state, operations, copy offload |
n3proc.c, nfsproc.c | NFSv2/v3 operations |
vfs.c, nfsfh.c, nfsfh.h | VFS interface, file handles, splice |
nfs4callback.c | Callbacks |
nfs4layouts.c | pNFS layouts |
filecache.c, nfscache.c | File cache, DRC |
export.c, nfsctl.c, netlink.c | Export mgmt, admin, netlink |
nfs4recover.c | Grace period, reclaim |
state.h, netns.h | Data structures |
The file-analyzer agent is designed to perform deep regression analysis on a single FILE-N group (all changes to a single source file) from a Linux kernel commit. It uses a multi-phase approach involving bulk context loading, subsystem guide analysis, and semcode-based code lookups to identify regressions.
Agent Configuration:
opusRead, Write, Search, and various mcp__plugin_semcode_semcode__ tools (e.g., find_function, find_type, find_callers, find_calls, find_callchain, grep_functions, find_commit).Core Constraints:
fs/bcachefs and test program issues (unless causing system instability).WARN, or BUG removals as regressions.semcode tools for lookups.---
name: file-analyzer
description: Performs deep regression analysis on a single FILE-N group
tools: Read, Write, Search, mcp__plugin_semcode_semcode__find_function, mcp__plugin_semcode_semcode__find_type, mcp__plugin_semcode_semcode__find_callers, mcp__plugin_semcode_semcode__find_calls, mcp__plugin_semcode_semcode__find_callchain, mcp__plugin_semcode_semcode__grep_functions, mcp__plugin_semcode_semcode__find_commit
model: opus
---The review documentation is organized into several specialized files. Use this table to determine which file to load based on the patch content being reviewed.
| File | Purpose | When to Load |
|---|---|---|
| review-core.md | Main entry point with review checklist | Always start here |
| technical-patterns.md | Core technical patterns and common bugs | Load first (per review-core.md) |
| coding-style.md | Complete style guide | Style questions, new files |
| argument-parsing.md | Argument handling patterns | Changes to argument parsing |
| json.md | JSON output implementation and validation | Changes to output functions |
| netlink.md | Netlink protocol patterns | Netlink request/response code |
| false-positive-guide.md | Avoiding incorrect review findings | When uncertain about violations |
Sashiko is a distributed system for tracking, applying, and reviewing Linux Kernel changes. It uses a modular, single-node architecture built with Rust's async runtime (tokio).
Core Workflow:
Patch and Patchset structures, detects git baselines, and applies them in a sandboxed Git worktree.The overview-analyzer agent performs a holistic analysis of an entire diff as a single unit. Unlike per-file or per-function agents, its primary purpose is to identify issues that span multiple hunks or functions—inconsistencies that are invisible when looking at individual changes in isolation.
To maintain efficiency, the agent adheres to strict boundaries:
side-effect.md).review.md).When working with the SMB/ksmbd subsystem, you must ensure that the negotiate response is the very first message that grants credits to the peer. Sending credit-granting messages (via data transfer messages) before the negotiate response causes protocol violations, connection failures, or undefined behavior on the client side.
Credits control the number of outstanding send requests. Credits are set via manage_credits_prior_sending() in two places:
smb_direct_send_negotiate_response() in fs/smb/server/transport_rdma.c.smb_direct_create_header().The smbdirect_socket structure (defined in fs/smb/common/smbdirect/smbdirect_socket.h) uses two work items that can trigger credit-granting sends:
| Work item | Handler (ksmbd) | Effect |
|---|---|---|
recv_io.posted.refill_work | smb_direct_post_recv_credits() | Posts receive buffers, then queues idle.immediate_work if any credits were posted |
idle.immediate_work | smb_direct_send_immediate_work() | Calls smb_direct_post_send_data() with zero payload, which sends a data transfer PDU carrying credits_granted |
The correct execution flow is: recv_io.posted.refill_work handler posts buffers $\rightarrow$ calls queue_work(sc->workqueue, &sc->idle.immediate_work) $\rightarrow$ idle.immediate_work handler sends the empty data transfer message that grants credits.
At EL2 in nVHE/pKVM, BUG_ON() and WARN_ON() both expand to BRK. This means there is no "warn and continue" semantics; the hypervisor will panic and the code following the macro is unreachable.
How to test if a WARN_ON(cond) is used correctly:
Determine if cond evaluates to true through contract-permitted inputs or only through invariant violations.
cond is true due to host-supplied input (post-de-privilege), allocator/lookup outcomes, hardware/firmware return values, or concurrency races. In these cases, the function should return an error instead of asserting.cond is true only when EL2's own internal invariants are violated (e.g., a slot EL2 just populated is NULL, or a refcount EL2 just incremented is zero).Critical Warning:
Patterns like if (WARN_ON(err)) { /* recovery */ } are dead code. The WARN_ON will trigger a BRK and panic before the recovery path is ever reached.
When using user namespaces, you must map container IDs to host IDs using the /proc/PID/uid_map and /proc/PID/gid_map files. The format for these files is:
<container_id> <host_id> <count>
Best Practices:
/etc/subuid and /etc/subgid if required by the system configuration.MS_BIND flag when used within a user namespace.To prevent integer truncation when ring buffers are large or write pointers exceed the 32-bit range, all write pointer (wptr) related variables, parameters, and struct fields must use the u64 type.
Required Types:
struct amdgpu_ring.wptr must be u64.struct amdgpu_fence.wptr must be u64.u64.// CORRECT: both wptr parameters are u64
static void func(struct amdgpu_ring *ring, u64 start_wptr, u64 end_wptr)When returning errors in a D-Bus context, use the appropriate sd_bus_error functions:
sd_bus_error_set_errno(error, r): Sets error based on an integer error code.sd_bus_error_set_errnof(error, r, "format", ...): Sets error with a custom message.sd_bus_error_set_const(error, CODE, "message"): Sets a well-known D-Bus error.In method callbacks, ensure all error paths set the sd_bus_error and that the success path explicitly returns a reply using sd_bus_reply_method_return.
/* Return error to caller */
return sd_bus_error_set_errno(error, r);
/* With custom message */
return sd_bus_error_set_errnof(error, r, "Failed to %s: %m", operation);
/* Well-known D-Bus error */
return sd_bus_error_set_const(error, SD_BUS_ERROR_INVALID_ARGS,
"Invalid argument");