aboutsummaryrefslogtreecommitdiffstats
path: root/syz-cluster/pkg/triage/commit.go
Commit message (Collapse)AuthorAgeFilesLines
* syz-cluster: prioritize blob-based base commitsAleksandr Nogikh2026-01-131-0/+37
| | | | | | | | | | | | | Consider Cc'd mailing lists when selecting the exact base commit. Among the base commits determined based on blob sha value from the git patch, first select the ones that match both the trees of the Cc'd subsystems and their primary branches. If it gives no exact match, select a base commit that comes from a tree of a Cc'd subsystem. As fallback, take any subsystem tree. This should prevent valid, but suprising patch series triage results.
* syz-cluster: guess base patch by blob hashes from the diffAleksandr Nogikh2026-01-091-2/+1
| | | | | Before traversing the list of trees, attempt to determine the base tree/commit by looking at the SHA hashes from the supplied git diffs.
* syz-cluster: log HEAD commit date during triageAleksandr Nogikh2025-11-281-1/+1
| | | | | | Currently triage logs look a bit confusing since for some commits they include author date and for other commit date. Use commit date everywhere.
* syz-cluster: share the series skip reasonAleksandr Nogikh2025-04-111-15/+26
| | | | | | | | The existing "no suitable commits found" reason is way too ambiguous. Make CommitSelector return the exact reason why it decides not to proceed with the particular patch series and display the reason on the web dashboard.
* syz-cluster: simplify the triage resultAleksandr Nogikh2025-02-181-13/+18
| | | | | | | | | | | Instead of giving several base commits to try, make the more concrete decision at the triage step and return only one option. This relies on the triager always having the information about the current state of the each tree, which will be added in the following commit. As the result, the workflow script becomes much simpler.
* syz-cluster: report series/sessions via APIAleksandr Nogikh2025-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | In the previous version of the code, series-tracker was directly pushing patch series into the DB and the controller auto-created fuzzing sessions. Mediate these via the controller API instead. Instead of creating Session objects on the fly, pre-create them and let processor take them one by one. The approach has multiple benefits: 1) The same API might be used for the patch series sources other than LKML. 2) If the existence of Session objects is not a sign that we have started working on it, it allows for a more precise status display (not created/waiting/running/finished). 3) We could manually push older patch series and manually trigger fuzzing sessions to experimentally measure the bug detection rates. 4) The controller tests could be organized only by relying on the API offered by the component.
* syz-cluster: initial codeAleksandr Nogikh2025-01-221-0/+67
The basic code of a K8S-based cluster that: * Aggregates new LKML patch series. * Determines the kernel trees to apply them to. * Builds the basic and the patched kernel. * Displays the results on a web dashboard. This is a very rudimentary version with a lot of TODOs that provides a skeleton for further work. The project makes use of Argo workflows and Spanner DB. Bootstrap is used for the web interface. Overall structure: * syz-cluster/dashboard: a web dashboard listing patch series and their test results. * syz-cluster/series-tracker: polls Lore archives and submits the new patch series to the DB. * syz-cluster/controller: schedules workflows and provides API for them. * syz-cluster/kernel-disk: a cron job that keeps a kernel checkout up to date. * syz-cluster/workflow/*: workflow steps. For the DB structure see syz-cluster/pkg/db/migrations/*.