| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Before traversing the list of trees, attempt to determine the base
tree/commit by looking at the SHA hashes from the supplied git diffs.
|
| |
|
|
|
| |
It will accelerate various commit search operations by orders of
magnitude.
|
| |
|
|
|
|
|
| |
Copy everything into the build context.
Add a .dockerignore file to avoid copying the definitely unnecessary
files and folders.
Check copyrights presence in Dockerfiles.
|
| |
|
|
|
|
|
|
| |
Remap remote branches to local ones both when polling remote
repositories and when cloning the distributed repository.
This will ensure that the branches are still accessible via
TreeName/BranchName (it got broken during the latest changes).
|
| |
|
|
|
|
|
|
|
|
| |
Instead of a complicated overlayfs setup, do a lightweight git clone in
a way that the cloned local copy keeps on referencing the git object
storage on the NFS.
It's simpler code-wise and hopefully will be less susceptible to
failures when local git operations coincide with a git fetch on the
shared repository.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When a triage or build step coincides with a cron job that polls new
kernel trees, they often fail due to git command noticing that the
repository is being updated.
In this case, the step logs an error and exits with status=1. Argo
workflows offers a functionality to retry such steps up to the specific
number of times and with exponentially increasing backoffs.
Configure the build and triage step templates to retry 3 times with 5
and then 10 minutes distance between the retries.
|
| |
|
|
|
|
|
|
| |
Instead of a predefined set of manually written syz-manager configs,
construct it dynamically from different bits.
During triage, select not just one, but all matching fuzzer
configurations and then merge them together.
|
| |
|
|
|
|
|
|
| |
During triage, process each fuzzing campaign separately as they may have
different base kernel revisions (e.g. if the newest revisions of the
kernel no longer build/boot under the specific kernel configuration).
Refactor the representation of the fuzzing targets in api.go.
|
| |
|
|
|
| |
Adjut the workflow template and the API to run multiple fuzzing
campaigns as a part of single patch series processing.
|
| |
|
|
|
|
| |
The image is to be deprecated.
Closes #6350.
|
| |
|
|
|
|
|
|
| |
Keep the fuzz-step parameters in a separate structure to minimize the
field duplication.
It will also facilitate the reuse of the same syzkaller config in
several fuzzing configurations.
|
| |
|
|
|
|
|
|
| |
Not always are fuzzing targets well represented by their own kernel
trees, so let's select a kernel tree and a fuzzing config separately.
Drop explicit priorities and instead just sort the lists of trees and
configs.
|
| |
|
|
|
|
|
|
|
| |
Even if the target tree is specified in the patch title, there happen to
be cases when it's actually only applicable to some other trees.
So instead of choosing one particular tree and sticking to it, obtain an
ordered list of candidates and pick the first to which the series
actually applies.
|
| |
|
|
|
|
|
|
| |
We used to only upload them on triage failure, but let's improve the
inspectability even for successfully finished triage jobs.
Slightly refactor the controller API around the triage result
submission.
|
| |
|
|
|
|
|
|
| |
Share not just the tree name (mainline, net, etc), but also the full URL
to check out the repository.
For that, add one more field to the Build entity and adjust email
reporting templates.
|
| |
|
|
|
| |
For some reason, it does not download the newer toolchain versions
automatically.
|
| |
|
|
| |
For now, only share it for the skipped series.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Refactor Tree structure to host both the kernel config and the fuzzer
config.
Add some basic net fuzzing configs.
|
| |
|
|
|
|
|
|
|
| |
Accept IMAGE_PREFIX and IMAGE_TAG parameters that allow to reuse the
Makefile and a lot of k8s configurations both for local and prod
environments.
Refactor Makefile: define build-* and push-* rules, use templates to
avoid repetition.
|
| |
|
|
|
|
| |
Once a new kernel revision becomes available, build it to figure out
whether it's buildable. This information will be used in the triage step
to figure out the right base kernel revision.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
It will be important once we deploy to GKE.
For now, let's set just some limits, we'll adjust them over time.
|
| |
|
|
|
|
|
|
| |
It lets immediately distinguish the series that were actually processed
from the series that were skipped early on.
By storing a string, we also make it apparent why exactly the series was
skipped.
|
|
|
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/*.
|
