| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Display a list of other versions of the same series on the series details page.
Fetch all series sharing the same title and render them in a new "Series Versions" table, allowing navigation between
different versions of a patch series.
|
| |
|
|
|
| |
Update SeriesFilter in pkg/db to include PatchName and SeriesName fields, implement the SQL logic to filter by these
fields case-insensitively, and expose these filters in the dashboard UI.
|
| | |
|
| |
|
|
|
| |
This will simplify debugging of mistriaged patch series that ended up
either not applying anywhere or ended up with a build error.
|
| |
|
|
|
|
|
| |
Check a few more URLs.
Add a TODO about the problem around template error handling - if we
stream the output directly to w, we cannot set the 500 status if a
problem happens somewhere mid-template.
|
| |
|
|
|
|
| |
Apart from just the total number of findings (some of which may end up
being non-reported), also display specifically the number of reports
that have found their way to the mailing lists.
|
| |
|
|
|
|
|
| |
Add a web dashboard page with the main statistics concerning patch
series fuzzing.
Improve the navigation bar on top of the page.
|
| | |
|
| |
|
|
|
| |
Take web dashboard URL from the config and use it to generate links for
logs, reproducers, etc.
|
| |
|
|
|
|
|
| |
Fill in build details per each finding and display that information in
the report email.
Extend the test that verifies how api.SessionReport is filled.
|
| | |
|
| | |
|
| |
|
|
|
| |
If the series was skipped during triage, show that in the status and let
users filter by it.
|
| |
|
|
| |
For now, only share it for the skipped series.
|
| |
|
|
| |
If the test artifacts are present, let the user download them.
|
| |
|
|
| |
Add a checkbox to only display the series for which there are findings.
|
| |
|
|
|
| |
Add simple Previous/Next navigation for the list of series.
For now, just rely on SQL's LIMIT/OFFSET functionality.
|
| |
|
|
| |
Update the Web UI to have a filter form on top of the index page.
|
| |
|
|
|
| |
For each series, display the Cc'd email list and let users filter the
patch series list by those addresses.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Provide an API to set up the reporting of finished sessions for which
syz-cluster collected reportable findings.
The actual sending of the results is to be done in a separate component
that would:
1) Call Next() to get the next report to send.
2) Call Confirm() to confirm that the report has been sent.
3) Call Upstream() if the report has been moderated and needs to be sent
to e.g. public mailing lists.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Convert errors to HTTP statuses in a uniform way.
Move http routes construction from main.go to handler.go.
|
| |
|
|
| |
Record the logs from the build and fuzzing steps.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Findings are crashes and build/boot/test errors that happened during the
patch series processing.
|
|
|
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/*.
|
