@@ -9,15 +9,15 @@ First step does DAG check to disallow loops and other CFG validation.
In particular it will detect programs that have unreachable instructions.
(though classic BPF checker allows them)
-Second step starts from the first insn and descends all possible paths.
-It simulates execution of every insn and observes the state change of
+Second step starts from the first instruction and descends all possible paths.
+It simulates execution of every instruction and observes the state change of
registers and stack.
At the start of the program the register R1 contains a pointer to context
and has type PTR_TO_CTX.
-If verifier sees an insn that does R2=R1, then R2 has now type
+If verifier sees an instruction that does R2=R1, then R2 has now type
PTR_TO_CTX as well and can be used on the right hand side of expression.
-If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=SCALAR_VALUE,
+If R1=PTR_TO_CTX and instruction is R2=R1+R1, then R2=SCALAR_VALUE,
since addition of two valid pointers makes invalid pointer.
(In 'secure' mode verifier will reject any type of pointer arithmetic to make
sure that kernel addresses don't leak to unprivileged users)
@@ -323,7 +323,7 @@ Register liveness tracking
In order to make state pruning effective, liveness state is tracked for each
register and stack slot. The basic idea is to track which registers and stack
-slots are actually used during subseqeuent execution of the program, until
+slots are actually used during subsequent execution of the program, until
program exit is reached. Registers and stack slots that were never used could be
removed from the cached state thus making more states equivalent to a cached
state. This could be illustrated by the following program::
@@ -5,7 +5,7 @@ Submitting patches: the essential guide to getting your code into the kernel
For a person or company who wishes to submit a change to the Linux
kernel, the process can sometimes be daunting if you're not familiar
-with "the system." This text is a collection of suggestions which
+with "the system". This text is a collection of suggestions which
can greatly increase the chances of your change being accepted.
This document contains a large number of suggestions in a relatively terse
@@ -468,11 +468,11 @@ ask to have an Acked-by: line added to the patch's changelog.
Acked-by: is often used by the maintainer of the affected code when that
maintainer neither contributed to nor forwarded the patch.
-Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
-has at least reviewed the patch and has indicated acceptance. Hence patch
-mergers will sometimes manually convert an acker's "yep, looks good to me"
-into an Acked-by: (but note that it is usually better to ask for an
-explicit ack).
+Acked-by: is not as formal as Signed-off-by:. It is a record that the
+acknowledger has at least reviewed the patch and has indicated acceptance.
+Hence patch mergers will sometimes manually convert an acknowledger's
+"yep, looks good to me" into an Acked-by: (but note that it is usually
+better to ask for an explicit ack).
Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
Signed-off-by: Prabhav Kumar Vaish <pvkumar5749404@gmail.com> --- Documentation/bpf/verifier.rst | 10 +++++----- Documentation/process/submitting-patches.rst | 12 ++++++------ 2 files changed, 11 insertions(+), 11 deletions(-)