From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD316224249 for ; Tue, 17 Mar 2026 15:31:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773761488; cv=none; b=ohf5BUCmeNLWGm8e2yi28ui8oniMtlLgHcmnNtxDxkV4EalD0Lrh8+vTX/Q2xaMP6fYslqqhBh+1fLkkbE2VUf6vYqpv+kkWp52PPjkxd/bYs0N+6/jG5JH1wMQpeL/qWzKLTPpQNN2GXlWvvG5xQ/8xFuX6WGOaKdr8fi+nKwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773761488; c=relaxed/simple; bh=PFnyggXhA+OZAu09dsWL91ybIhdeJVT+Ul/lNaPvU3k=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=DuHRbGs4j8KnTw4aAvrWfxR7pt8Rbz9yo/D67QebRr6ZoevpQe0BrEfk9STnN1O5SuELE/aJ3FOs5dWd8mxPV75I8tmkJddL3X6SQB1s9NbUDN0+fS7p7WqP4X4OHLMS77BuIYHIVXV1IH1A2+8dfuMxftj+yqstAoaD5lUz09A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=bbgxr0JE; arc=none smtp.client-ip=91.218.175.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="bbgxr0JE" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773761483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=wX42K/z3FsPYAdaIoFKCeZE4LAd72JHdpR0DXlkky8E=; b=bbgxr0JEOH1prX/xKFxFcxknnpibFVEdauPSREDyOTAxZEpbhUh9V4K88E9TsdLcn/DwfC jeXBv7fWNe2tApyv2xQpII0D7hgsU/GZttrn7PnRB5ihOsVqVvmxTuyRstchhcnDzeLQnp Y9aXhmSCndWbIIlLjell2LTk8vBeVpw= From: Roman Gushchin To: linux-kernel , Andrew Morton , Theodore Ts'o , Guenter Roeck , Konstantin Ryabitsev , Chris Mason , SeongJae Park , elkin@google.com, Christian Brauner , Dmitry Vyukov , Sasha Levin , Shakeel Butt , Lorenzo Stoakes , Sean Christopherson , Ian Rogers Subject: Introduce Sashiko (agentic review of Linux kernel changes) Date: Tue, 17 Mar 2026 15:31:11 +0000 Message-ID: <7ia4o6kmpj5s.fsf@castle.c.googlers.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Hello, I'm happy to share something my colleagues and I have been working on for the last several months: Sashiko - an agentic system for Linux kernel changes. First, Sashiko is available as a service at: * https://sashiko.dev It reviews all patches sent to LKML and several other Linux kernel mailing lists using the Gemini 3.1 Pro model. I want to thank my employer, Google, for providing the ML compute resources and infrastructure for making this project real. Sashiko is written in Rust from scratch, mostly using Gemini CLI. It's fully self-contained and does not rely on any CLI coding tools. It supports various LLMs (at this moment mostly tested with Gemini Pro/Flash and slightly with Claude). And finally it's fully open-source: * https://github.com/sashiko-dev/sashiko It's licensed under the Apache-2.0 License, and the ownership of the project was transferred to the Linux Foundation. Contributions are really welcome using DCO. Sashiko is based on a set of open-source prompts initially developed by Chris Mason: * https://github.com/masoncl/review-prompts/ But Sashiko leverages a different multi-stage review protocol, which somewhat mimics the human review process and forces the LLM to look at the proposed change from different angles. In my measurement, Sashiko was able to find 53% of bugs based on a completely unfiltered set of 1,000 recent upstream issues using "Fixes:" tags (using Gemini 3.1 Pro). Some might say that 53% is not that impressive, but 100% of these issues were missed by human reviewers. Also, many of these issues (like tricky build failures, performance problems, etc) are very hard/impossible to spot from reviewing the code, so arguably 100% is not reachable. We started with low 30's a couple of months ago; better models and improvements in the review protocol and subsystem prompts pushed it to low 50's. With better LLMs and collective effort on prompts we can push even further. Measuring false positives is much harder, but based on manual reviews of reviews, it's pretty good: it's rarely dead wrong, but sometimes it can nitpick or find too many low-value issues. In many cases, it can be improved with prompt engineering. * What's next? This is our first version and it's obviously not perfect. There is a long list of fixes and improvements to make. Please, don't expect it to be 100% reliable, even though we'll try hard to keep it up and running. Please use github issues or email me any bug reports and feature requests, or send PR's. As of now, Sashiko only provides a web interface; however, Konstantin Ryabitsev is already adding sashiko.dev support to b4, and SeongJae Park is adding support to hkml. That was really fast, thank you! We're working on adding an email interface to Sashiko, and soon Sashiko will be able to send out reviews over email - similar to what the bpf subsystem already has. It will be opt-in by subsystem and will have options to CC only the author of the patch, maintainers, volunteers, or send a fully public reply. If you're a maintainer and have a strong preference to get reviews over email, please let me know. We also desperately need better benchmarks, especially when it comes to false positives. Having a decent vetted set of officially perfect commits can help with this. Finally, some subsystems have a good prompts coverage and some don't. It doesn't have to be lengthy documentation (and it might actually be counter-productive), but having a small list of things to look at - some high-level concepts which are hard to grasp from the code, etc. - can help a lot with both bug discovery and false positives. Thanks, Roman