Signed-off-by: Prabhav Kumar Vaish <pvkumar5749404@xxxxxxxxx> --- Documentation/bpf/verifier.rst | 10 +++++----- Documentation/process/submitting-patches.rst | 12 ++++++------ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst index f0ec19db301c..1b39809277d2 100644 --- a/Documentation/bpf/verifier.rst +++ b/Documentation/bpf/verifier.rst @@ -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:: diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 66029999b587..34a68836aa60 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -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 -- 2.34.1
