diff options
| author | Davidlohr Bueso <dave.bueso@gmail.com> | 2023-06-06 13:57:27 -0700 |
|---|---|---|
| committer | Aleksandr Nogikh <wp32pw@gmail.com> | 2023-06-07 12:49:35 +0200 |
| commit | a87f55960b1c75aa2372576b6bcae0d003ace8a9 (patch) | |
| tree | fd133cb927fcc6eae09b1c88789366a63dd3e99d /docs/syzbot.md | |
| parent | d0f31f8953ac80bcac72a36936ed345c65e51262 (diff) | |
docs: typo fixes
Fix various typos within the documentation directory.
Diffstat (limited to 'docs/syzbot.md')
| -rw-r--r-- | docs/syzbot.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/docs/syzbot.md b/docs/syzbot.md index f4e554376..568a53612 100644 --- a/docs/syzbot.md +++ b/docs/syzbot.md @@ -432,7 +432,7 @@ propagation of uninitialized values through memory and registers and only flags actual eventual uses of uninitialized values. For example, `KMSAN` will detect a branch on or a `copy_to_user()` of values that transitively come from uninitialized memory created by heap/stack allocations. This ensures -/theoretical/ absense of both false positives and false negatives (with some +/theoretical/ absence of both false positives and false negatives (with some implementation limitations of course). Note that `KMSAN` requires `clang` compiler. `KMSAN` is not upstream yet, though, we want to upstream it later. For now, @@ -450,7 +450,7 @@ and attach/inline your test patch in the same email. Report explanation. The first call trace points to the `use` of the uninit value (which is usually a branching or copying it to userspace). Then there are 0 or more "Uninit was stored to memory at:" stacks which denote how the unint value -travelled through memory. Finally there is a "Uninit was created at:" +traveled through memory. Finally there is a "Uninit was created at:" section which points either to a heap allocation or a stack variable which is the original source of uninitialized-ness. @@ -516,11 +516,11 @@ There are several reasons for this: - custom patches may not apply tomorrow - custom patches may not apply to all of the tested git trees - it's hard to communicate exact state of the code with bug reports (not just hash anymore) -- line numbers won't match in reports (which always brings suspecion as to the quality of reports) +- line numbers won't match in reports (which always brings suspicion as to the quality of reports) - custom patches can also introduce bugs, and even if they don't a developer may (rightfully) question validity of and may not want to spend time on reports obtained with a number of out-of-tree patches -- order of patch application generatelly matters, and at some point patches +- order of patch application generally matters, and at some point patches need to be removed, there is nobody to manage this We've experimented with application of custom patches in the past and it lead |