aboutsummaryrefslogtreecommitdiffstats
path: root/syz-cluster/pkg/api
Commit message (Collapse)AuthorAgeFilesLines
* syz-cluster: poll the media treeAleksandr Nogikh2026-01-091-0/+6
| | | | | | Poll the tree and consider it during patch series triage. Note that the media lists are not monitored as of now, so the tree will only be used when we receive media patches through other mailing lists.
* syz-cluster: basic support for finding invalidationAleksandr Nogikh2025-12-012-0/+6
| | | | | | Add some initial #syz invalid support to syz-cluster. For now, mark all findings as invalid and don't display that such series have findings on the web dashboard.
* syz-cluster: poll drm treeAleksandr Nogikh2025-11-121-0/+6
| | | | | | | | Add the drm tree to the list of trees considered during patch series triage. Currently we sometimes hit false positives becase of not considering this tree, see e.g. https://ci.syzbot.org/series/1ecba15f-79c3-40ff-99c6-8f3540bddf65
* syz-cluster: checkout the mm-new treeAleksandr Nogikh2025-10-201-0/+6
| | | | | | A number of mm patches do not apply neither on top of torvalds, nor on top of linux-next. The mm/mm-new branch seems to be a more reliable base.
* syz-cluster: rewrite fuzz config generationAleksandr Nogikh2025-10-071-48/+46
| | | | | | | | 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.
* syz-cluster: support multiple campaigns per fuzz targetAleksandr Nogikh2025-10-072-48/+82
| | | | | | | | 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.
* syz-cluster: prefix fuzzing-related stepsAleksandr Nogikh2025-10-011-0/+10
| | | | | Specify a track name for each fuzzing campaign. It will help distinguish them once there are multiple ones.
* syz-cluster: configure bug title filterAleksandr Nogikh2025-10-011-0/+2
| | | | | Instead of just checking whether the bug was observed on the base crash, accept a regexp of accepted bug titles as well.
* syz-cluster: support multiple fuzz tasksAleksandr Nogikh2025-10-011-1/+1
| | | | | Adjut the workflow template and the API to run multiple fuzzing campaigns as a part of single patch series processing.
* syz-cluster: fetch linux-nextAleksandr Nogikh2025-09-031-1/+7
| | | | | | | | There are a number of patch series that don't apply to torvalds, but do apply to linux-next. Since we don't fetch all maintainer trees, use linux-next as the last resort.
* syz-cluster: add kvm/next treeAleksandr Nogikh2025-08-291-0/+6
| | | | | Some series don't apply to torvalds, see e.g. https://ci.syzbot.org/series/f429573e-7862-4f1e-97dd-3215a235b1d3
* syz-cluster: fuzz block patch seriesAleksandr Nogikh2025-08-261-0/+1
|
* syz-cluster: define a separate fs configAleksandr Nogikh2025-08-211-0/+13
| | | | | When fuzzing fs-related series, enable fs syscalls and use the fs corpus.
* syz-cluster: collect information about base crashesAleksandr Nogikh2025-08-211-0/+18
| | | | Track base crashes for (commit hash, config, arch) tuples.
* syz-cluster: skip fuzzing if binaries are the sameAleksandr Nogikh2025-08-191-0/+1
| | | | | | | | If all symbol hashes between the base and the pathed kernel match, there's no reason to spend time fuzzing the series. Add a 'skipped' status to the enum of possible session test results and set it from the fuzz-step.
* syz-cluster: fuzz new mm patch seriesAleksandr Nogikh2025-08-121-0/+10
|
* syz-cluster: skip coverage checks for some fuzz targetsAleksandr Nogikh2025-08-121-0/+2
| | | | | | | | There are cases when we do not need the "if the patched code is not reached within 30 minutes, abort fuzzing" check. This is e.g. the case of mm/ code that is not fully instrumented by KCOV.
* syz-cluster: refactor fuzz config structuresAleksandr Nogikh2025-08-122-20/+35
| | | | | | | | 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.
* syz-cluster: fuzz linux-wireless patch seriesAleksandr Nogikh2025-08-061-2/+6
|
* syz-cluster: fuzz io-uring patch seriesAleksandr Nogikh2025-08-061-0/+6
| | | | Use a custom set of enabled syscalls.
* syz-cluster: add a kvm configAleksandr Nogikh2025-07-311-0/+6
| | | | | Add a config to fuzz kvm patches. Listen on the kvm mailing list.
* syz-cluster: split tree and fuzz config selectionAleksandr Nogikh2025-07-312-72/+64
| | | | | | | | 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.
* syz-cluster: always upload triage logsAleksandr Nogikh2025-07-282-8/+9
| | | | | | | | 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.
* syz-cluster: add bpf tree info and configsAleksandr Nogikh2025-07-241-1/+22
| | | | | | Fuzz bpf patches differently from net patches. Monitor netfilter and bpf mailing lists
* syz-cluster: fix the netdev-next tree URLAleksandr Nogikh2025-07-231-1/+1
|
* syz-cluster: prefer net-next and nf-nextAleksandr Nogikh2025-07-221-4/+4
| | | | | | | Current results show that way too many series do not apply to the non-next versions of their corresponding trees. So let's make -next the default choice unless it the opposite was specified in the series subject.
* syz-cluster: add more kernel treesAleksandr Nogikh2025-07-221-10/+41
| | | | | Add several more network-related trees, including those that will only be selected if mentioned directly.
* syz-cluster: remember LKML series tagsAleksandr Nogikh2025-07-221-0/+1
| | | | | Sometimes the patch series directly hint at the kernel tree they should be applied to. Extract and remember this information.
* syz-cluster: keep only one Cc list in SessionReportAleksandr Nogikh2025-07-171-1/+0
| | | | | | | | | Currently, the list was both within the Series object and within the SessionReport object that also encloses Series. And, since only was was actually filled, we were unable to actually Cc the people from the series. Keep only the Cc list in the Series object and adjust the tests.
* syz-cluster: remember and share kernel tree URLsAleksandr Nogikh2025-07-171-1/+4
| | | | | | | | 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.
* syz-cluster: upload and share build config and logAleksandr Nogikh2025-07-142-0/+9
|
* syz-cluster: generate web dashboard URLs for reportsAleksandr Nogikh2025-07-141-0/+31
| | | | | Take web dashboard URL from the config and use it to generate links for logs, reproducers, etc.
* syz-cluster: make reports more detailedAleksandr Nogikh2025-07-141-2/+2
| | | | | | | 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.
* syz-cluster: make report reply tracking more flexibleAleksandr Nogikh2025-07-021-11/+3
| | | | | | Replace an UpdateReport() call with a RecordReply(). This will eventually allow us to support the email sender implementations for which we do not immediately know the MessageID of the reported message.
* syz-cluster: save and display reproducers for findingsAleksandr Nogikh2025-06-231-5/+8
|
* syz-cluster: add reply tracking functionalityAleksandr Nogikh2025-05-131-0/+28
| | | | | Add API to record replies under the reports that allows to determine the original report only by having the MessageID.
* syz-cluster: make reporter names more specificAleksandr Nogikh2025-05-131-1/+1
| | | | | | | | Since email-reporter is anyway tied to a specific reporting channel, let's keep reporter names less generic. Using "lkml" instead of just "email" will also let us generate proper links to the email discussions based only on Reporter+MessageID.
* syz-cluster: support multiple reporter typesAleksandr Nogikh2025-05-091-5/+9
| | | | | Introduce a Reporter column to the SessionReport. For finished reports, store both a MessageID instead of Link.
* syz-cluster: share and display triage logsAleksandr Nogikh2025-04-111-1/+2
| | | | For now, only share it for the skipped series.
* syz-cluster: provide API for uploading artifacts archiveAleksandr Nogikh2025-04-112-0/+35
| | | | | | | | | | | The archive would be a useful source of debugging information. Provide an HTTP endpoint that accepts a multipart form request with the archived data. Provide an *api.Client method to encapsulate the encoding of the data. Add a test.
* syz-cluster: download latest corpuses from syzbotAleksandr Nogikh2025-03-111-3/+18
|
* syz-cluster: add net configAleksandr Nogikh2025-03-111-12/+23
| | | | | | Refactor Tree structure to host both the kernel config and the fuzzer config. Add some basic net fuzzing configs.
* syz-cluster/pkg/report: add an email templateAleksandr Nogikh2025-02-191-9/+20
| | | | | | | | The first revision of the email template that will be used for reporting the findings. This PR adds more fields to the pkg/api package, but these are not filled by the implementation yet. That will be done separately.
* syz-cluster: build latest revisions of base kernelsAleksandr Nogikh2025-02-182-5/+13
| | | | | | 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.
* syz-cluster: simplify the triage resultAleksandr Nogikh2025-02-181-7/+6
| | | | | | | | | | | 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/pkg/api: consider another repoAleksandr Nogikh2025-02-141-1/+2
| | | | | Leave a TODO with a better Linux repository mirror. We still need to double-check that it works fine on syz-cluster before switching to it.
* syz-cluster: report session resultsAleksandr Nogikh2025-02-144-26/+131
| | | | | | | | | | | | 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.
* syz-cluster: report series/sessions via APIAleksandr Nogikh2025-02-142-7/+49
| | | | | | | | | | | | | | | | | | | | | | 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/pkg/api: set deadlines for requestsAleksandr Nogikh2025-02-041-19/+18
| | | | | | Refactor the helper methods to reduce code duplication. Add context argument support for GET methods. Add a one minute deadline on top of the deadline imposed by the context.
* syz-cluster: explicitly set the skip reasonAleksandr Nogikh2025-01-272-1/+10
| | | | | | | | 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.
generated by ggit (джигит) mrf-deployment (git 2.46.0) at 2026-03-12 12:48:27 +0000