All of lore.kernel.org
 help / color / mirror / Atom feed
From: PrittSpadeLord <pritt1999@gmail.com>
To: netfilter-devel@vger.kernel.org
Cc: PrittSpadeLord <pritt1999@gmail.com>
Subject: [PATCH] minor spelling and grammar fixes in doc
Date: Sat, 20 Jun 2026 14:07:17 +0530	[thread overview]
Message-ID: <20260620083719.115461-1-pritt1999@gmail.com> (raw)

Signed-off-by: PrittSpadeLord <pritt1999@gmail.com>
---
 doc/nft.txt                | 8 ++++----
 doc/payload-expression.txt | 8 ++++----
 doc/statements.txt         | 2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/doc/nft.txt b/doc/nft.txt
index cee92c2b..0f37782c 100644
--- a/doc/nft.txt
+++ b/doc/nft.txt
@@ -592,7 +592,7 @@ This is a summary of how the ruleset is evaluated.
 * For each hook, the attached chains are evaluated in order of their priorities.
   Chains with lower priority values are evaluated before those with higher ones.
   The order of chains with the same priority value is undefined.
-* An *accept* verdict (including an implict one via the base chain’s policy)
+* An *accept* verdict (including an implicit one via the base chain’s policy)
   ends the evaluation of the current base chain.
   It is not relevant if the *accept* verdict is issued in the base chain itself
   or a regular chain called from the base chain.
@@ -601,7 +601,7 @@ This is a summary of how the ruleset is evaluated.
   chain policy issues a *drop* verdict.
   All this applies to verdict-like statements that imply *accept*,
   for example the NAT statements.
-* A *drop* verdict (including an implict one via the base chain’s policy)
+* A *drop* verdict (including an implicit one via the base chain’s policy)
   immediately ends the evaluation of the whole ruleset.
   No further chains of any hook are consulted.
   It is therefore not possible to have a *drop*
@@ -611,7 +611,7 @@ This is a summary of how the ruleset is evaluated.
   Thus, if any base chain uses drop as its policy, the same base chain (or a
   regular chain directly or indirectly called by it) must contain at least one
   matching *accept* rule or the packet will be dropped.
-* Given the semantics of *accept*/*drop* and only with respect to the utlimate
+* Given the semantics of *accept*/*drop* and only with respect to the ultimate
   decision of whether a packet is accepted or dropped, the ordering of the
   various base chains per hook via their priorities matters only in so far, as
   any of them modifies the packet or its meta data and that has an influence on
@@ -767,7 +767,7 @@ Without this flag, *1.2.3.2* can not be added and *1.2.3.5* is inserted as a new
 Equality of a value with a set is given if the value matches exactly one value
 in the set (which for intervals means that it’s contained in any of them).
 See <<BITMASK_TYPE>> for the subtle differences between syntactically similarly
-looking equiality checks of sets and bitmasks.
+looking equality checks of sets and bitmasks.
 
 MAPS
 -----
diff --git a/doc/payload-expression.txt b/doc/payload-expression.txt
index 817b7a3c..ceccfdaa 100644
--- a/doc/payload-expression.txt
+++ b/doc/payload-expression.txt
@@ -594,7 +594,7 @@ GENEVE HEADER EXPRESSION
 *geneve* *udp* {*sport* | *dport* | *length* | *checksum*}
 
 The geneve expression is used to match on the geneve header fields. The geneve
-header encapsulates a ethernet frame within a *udp* packet. This expression
+header encapsulates an ethernet frame within a *udp* packet. This expression
 requires that you restrict the matching to *udp* packets (usually at
 port 6081 according to IANA-assigned ports).
 
@@ -647,7 +647,7 @@ VXLAN HEADER EXPRESSION
 *vxlan* *udp* {*sport* | *dport* | *length* | *checksum*}
 
 The vxlan expression is used to match on the vxlan header fields. The vxlan
-header encapsulates a ethernet frame within a *udp* packet. This expression
+header encapsulates an ethernet frame within a *udp* packet. This expression
 requires that you restrict the matching to *udp* packets (usually at
 port 4789 according to IANA-assigned ports).
 
@@ -707,7 +707,7 @@ inet filter input meta l4proto {tcp, udp} th dport { 53, 80 }
 it is more convenient, but like the raw expression notation no
 dependencies are created or checked. It is the users responsibility
 to restrict matching to those header types that have a notion of ports.
-Otherwise, rules using raw expressions will errnously match unrelated
+Otherwise, rules using raw expressions will erroneously match unrelated
 packets, e.g. mis-interpreting ESP packets SPI field as a port.
 
 .Rewrite arp packet target hardware address if target protocol address matches a given address
@@ -935,4 +935,4 @@ ct_id|
 --------------------
 nft add set filter ssh_flood '{ type ipv4_addr; flags dynamic; }'
 nft add rule filter input ct state new tcp dport 22 add @ssh_flood '{ ip saddr ct count over 2 }' reject
---------------------
+--------------------
\ No newline at end of file
diff --git a/doc/statements.txt b/doc/statements.txt
index 8f96bf6b..7f7b5e60 100644
--- a/doc/statements.txt
+++ b/doc/statements.txt
@@ -795,7 +795,7 @@ unsigned integer (16 bit)
 |==================
 |Flag | Description
 |bypass |
-Let packets go through if userspace application cannot back off. Before using
+Let packets go through if the userspace application cannot back off. Before using
 this flag, read libnetfilter_queue documentation for performance tuning recommendations.
 |fanout |
 Distribute packets between several queues.
-- 
2.54.0


                 reply	other threads:[~2026-06-20  8:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260620083719.115461-1-pritt1999@gmail.com \
    --to=pritt1999@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.