| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
Not all reports are real bugs, so let's use softer wording.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a single global `config` variable and access it
throughout the whole dashboard application.
However, this approach has been more and more complicated test writing
-- sometimes we want the config to be only slightly different, so that
it's not worth it adding new namespaces, sometimes we have to test how
dashboard handles config changes over time.
This has already led to a number of hacky contextWithXXX methods that
mocked various parts of the global variable. The rest of the code had to
sometimes still use `config` directly and sometimes invoke getXXX(c)
methods. This is very inconsistent and prone to errors.
With more and more situations where we need to patch the config
appearing (see #4118), let's refactor the application to always access
config via the getConfig(c) method. This allows us to uniformly patch
the config and be sure that the non-patched copy is not accessible from
anywhere else.
|
| |
|
|
|
|
|
| |
In some cases restarting the failed bisection does not make sense,
because we know that the result will be the same.
Let admins choose between invalidating the job and restarting it.
|
| |
|
|
|
| |
Update the bug cheatsheet to emphasise that "#syz set subsystems" does
not add new subsystems, but rather overwrites the whole list.
|
| |
|
|
|
| |
Accept only normal fix bisections as a reason to auto-close a bug if
FixBisectionAutoClose is set to true.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Changes to our rootfs, compilers or bisection logic regularly cause
regressions in our bisection accuracy. Retrying them currently entails
fiddling with the GCP datastore directly or mass deleting all failed
bisections.
This change will allow us to retry specific bisections with a single
click.
|
| |
|
|
|
|
|
|
|
| |
If a reproducer was revoked as a result of a fix bisection, we would
query and update Bug twice during the same transaction. But datastore
follows the "Read Committed" policy, so we de facto lose the updates of
the HeadReproLevel.
Ensure that we query and save Bug only once during doneJob.
|
| |
|
|
|
|
|
| |
Otherwise we only display #syz test hints for bugs which originally had
a reproducer.
Also, change the wording a bit.
|
| |
|
|
|
| |
We don't mention the whole list of #syz set labels there, so it will
only confuse people.
|
| |
|
|
|
|
|
|
| |
This should make commands more visible to the users and help those who
don't remember the exact syntax and don't want to always visit the
documentation page.
Ignore sample commands during incoming message parsing.
|
| |
|
|
|
| |
syz-cis call the method every 10 seconds, there's no sense in executing
the heavy logic that much often.
|
| |
|
|
|
|
|
| |
Modify job_poll never to return already started jobs.
Introduce a special job_reset API call to clear the "started" flag for
the specified list of managers.
|
| |
|
|
|
| |
Make it more clear - de facto we're just sending the report to the next
reporting stage.
|
| |
|
|
|
|
|
|
|
|
| |
Currently the dashboard does not report unreliable bisections
themselves, but there was a way in which they could still leak. The
recently detected case is when the bisection was done using a syz repro,
no reporting was made, but with a message about a newly found C repro
syzbot included the bisection info and Cc'd bisection-sourced emails.
Fix that behavior and introduce one new test.
|
| |
|
|
|
|
| |
1. Updated the "include"s.
2. No logs read API in the AppEngine anymore. Replaced by the GCP logging API.
3. Use "GO111MODULE=off gcloud beta app deploy ./dashboard/app/app.yaml --no-promote" to test new deployment.
4. Updated the documentation.
|
| |
|
|
|
| |
* dashboard/app: funcs GET and AuthGET are similar
* dashboard/app: funcs GET and POST are similar
* dashboard/app: uplevel httpRequest calls to GET or AuthGET
|
| |
|
|
|
|
|
|
|
| |
Currently email and web templates use 8 byte representation of commit
hashes. While this is enough for syzkaller, it becomes less and less
suitable for Linux kernel tags.
Switch to 12 byte representation for all Linux kernel commit hash
mentions.
|
| |
|
|
| |
Fixes #2435
|
| |
|
|
|
|
| |
Currently we can CC specific people for bugs on a particular kernel repo
(always, upstream, for build bugs). Add similar functionality for bugs
on a particular manager. This will be needed to CC people on clang instances.
|
| |
|
|
|
|
|
|
| |
1. Split cause/fix bisections in the bug table.
2. Show if bisection is inconclusive/unreliable in the bug table.
3. Show if bisection is unreliable on the bug page.
Update #2098
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've got several complains re using of word "crash" in all syzbot reports, e.g.:
https://groups.google.com/d/msg/syzkaller-bugs/8rFLFgQR9fo/HBYUXIRyBAAJ
https://groups.google.com/d/msg/syzkaller-bugs/3nlcT8Wn7hg/8Th16X3DBAAJ
Another suggested that "crash" is too hard for e.g. a LOCKDEP splat:
https://groups.google.com/d/msg/syzkaller/YzHLAU0dXpI/WOqq1ggBBQAJ
Another terminology complaint was regarding the following fact.
When we test a patch, we only detect if it still triggers _any_ issue
(not necessary the original one). Currently we way "still triggers crash"
(without any article, which is probably wrong from English perspective
anyway). We did not say "the", but people assumed that and complained.
Explicitly say "a".
Also replace all uses of "bug" with "issue" for consistency.
And use "final oops" instead of "final crash", which seems
to be standard terminology at least for Linux:
https://en.wikipedia.org/wiki/Linux_kernel_oops
|
| |
|
|
|
|
|
| |
Fix capitalization, dots at the end
and two spaces after a period.
Update #1876
|
| |
|
|
|
|
|
|
| |
Some terms are normalised on the technical level
but may be oppressive on a societal level.
Replace them with more technically neutral terms.
See the following doc for a longer version:
https://tools.ietf.org/id/draft-knodel-terminology-00.html
|
| |
|
|
| |
Checks for too long functions (based on lines and statements).
|
| |
|
|
|
| |
A good one. Lots of fixed comments are contributed by episodic contributors.
So it's good to catch these earlier.
|
| |
|
|
|
|
|
| |
Currently only ignores the commit that adds the Raw Gadget interface.
Requested here:
https://groups.google.com/g/syzkaller-bugs/c/sZUeGC3Fh-o/m/t_5cKPrMAQAJ
|
| |
|
|
| |
Newer version started producing more warnings. Fix them.
|
| |
|
|
|
|
|
|
|
|
| |
0. Remove aetest build tag. We don't need it anymore, go test should work.
1. IsDevAppServer does not return true in tests anymore, so don't use it
2. Use a different mechanism to register test/prod config.
We don't have aetest tag anymore, so we need something even more dynamic.
3. Fix new golangci-lint warnings: all test files are checked now.
Update #1461
|
| |
|
|
|
|
|
|
|
| |
The old go 1.9 App Engine runtime is now deprecated. Update to the go 1.11
runtime, which still allows us to use the old App Engine library (removed
in the 1.12 runtime).
Closes: #1461 ("dashboard: port app to go111/go112 runtime")
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
|
| |
|
|
|
| |
Some backport-only kernels may only be interested in fix bisections.
Allow enabling these separately.
|
| |
|
|
|
|
|
|
|
|
|
| |
They should have been detected by "same binary" logic.
But the problem is that we may use different compilers
for different commits and they switch exactly at release commits.
So we can build the release with a differnet compiler than the
rest of commits and then obviously it won't be "same binary".
Detect release commits separately.
Update #1271
|
| |
|
|
|
| |
Add an optional feature for subj.
Should be useful for unmaintained namespaces like Linux LTS.
|
| |
|
|
|
|
|
| |
Add new lines around bisection block as it was before.
Remove kernel tree, does not seem to be critical.
Make it clear what is cause bisection and what is fix bisection
(currently we have 2 "Bisection" which is not very helpful).
|
| |
|
|
|
|
|
|
| |
Detect bisection to merge commits and to commits that don't affect
kernel binary (comments, other arches, whitespaces, etc).
Such bisections are not reported in emails (but shown on web).
Update #1271
|
| |
|
|
|
|
|
|
|
| |
* When fix bisections fails due to a crash on HEAD, the dashboard needs to
keep track of which commit the crash occured at. In order to do this,
send correct commit information to the dashboard.
* Modify mail_bisect_result.txt to be clearer on what
BisectResult.KernelCommit represents. Modify test in bisect_test.go to
accommodate the changes in templates.
|
| |
|
|
|
| |
As requested by users.
Fixes #1396
|
| |
|
|
|
|
| |
* Fix a typo in mail_bisect_result.txt related to the "syz fix:" line.
* Improve the description to make it clearer why sending a "syz fix:" is
important.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Modify mail_bisect_result.txt to allow for sending fix bisection
results.
* Modify BisectResult to have a Fix field; introduce selectBisect for
use within the template for choosing between BisectCause/BisectFix
fields.
* Modify bisectFromJob() to return BisectResult with Fix field set if
relevant.
* Modify the tests inside bisect_test.go to account for bisect fix
related reporting emails.
* Modify incomingMail() to ignore any emails from syzbot itself.
|
| |
|
|
|
|
|
|
|
|
|
| |
* Modify uiBug type. Rename BisectCause to BisectCauseDone. Introduce
BisectFixDone.
* Modify createUIBug() and MergeUIBug() to set the above fields
appropriately.
* Modify bug_list to display the bisection status; remove yesSort() as
it is not used anymore. Adjust ".list_table .stat" to appropriate width.
* Add TestBugBisectionStatus() to check bisection status on main page.
* Add file from running "make generate": pkg/html/generated.go
|
| |
|
|
|
|
|
|
|
|
|
| |
* Modify the dashboard/app/bug.html template to show fix bisection
results.
* Modify handleBug() to fetch and create a uiJob for fix bisection
results.
* Modify loadBisectJob() to fetch jobs based on a specified jobType.
Change all callers to pass in jobType info into loadBisectJob().
* Add TestBugBisectionResults() to ensure bisection results show up as
expected.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Modify createBisectJob() to retrieve bugs that are potential candidates for both
BisectCause and BisectFix.
* Modify TestBisectCause() to account for BisectFix jobs that are
returned when polling.
* Add TestBisectFixJob() to check that BisectFix jobs are returned only
after 30 days of reporting.
* pollCompletedJobs() is currently called to fetch finished bisection
jobs for reporting purposes. Modify it to not return BisectFix jobs so
that they are not reported.
|
| |
|
|
|
|
|
|
|
|
| |
We override crash with the crash used for bisection
to make the information more consistent.
However if bisection crash only have syz repro
and there is now another crash with C repro,
then we always think that we have not reported C repro
and continue sending the same report again and again.
Don't override the crash with bisection crash in such case.
|
| |
|
|
|
|
|
|
| |
Add link to more information about bisection process
to emails that contain bisection results.
This seems to be a hot topic for questions.
Update #501
|
| |
|
|
|
|
|
| |
@ebiggers pointed out that Fixes tags should use 12-char hash:
https://groups.google.com/d/msg/syzkaller-bugs/yUhRrLD6T6A/3TMwOWvWAgAJ
I can't find any documentation on this, but it looks like most
existing tags follow this convention so use 12-char hashes.
|
| |
|
|
|
|
|
|
| |
Allow separate sets of managers for patch testing and for bisection.
This makes things more flexible on syz-ci deployment side.
Remove previous hacks for bisection deployment.
Update #501
|
| |
|
|
| |
Update #501
|
| | |
|