diff --git a/docs/ebpf-library/libbpf/ebpf/BPF_CORE_READ.md b/docs/ebpf-library/libbpf/ebpf/BPF_CORE_READ.md
index 9578d3ca..529f6f17 100644
--- a/docs/ebpf-library/libbpf/ebpf/BPF_CORE_READ.md
+++ b/docs/ebpf-library/libbpf/ebpf/BPF_CORE_READ.md
@@ -65,7 +65,7 @@ SEC("kprobe.multi/__netif_receive_skb_core*")
 int bpf_prog1(struct pt_regs *ctx)
 {
 	/* attaches to kprobe __netif_receive_skb_core,
-	 * looks for packets on loobpack device and prints them
+	 * looks for packets on loopback device and prints them
 	 * (wildcard is used for avoiding symbol mismatch due to optimization)
 	 */
 	char devname[IFNAMSIZ];
diff --git a/docs/ebpf-library/libbpf/ebpf/BPF_KPROBE.md b/docs/ebpf-library/libbpf/ebpf/BPF_KPROBE.md
index 2f5cd27c..c04151f6 100644
--- a/docs/ebpf-library/libbpf/ebpf/BPF_KPROBE.md
+++ b/docs/ebpf-library/libbpf/ebpf/BPF_KPROBE.md
@@ -9,7 +9,7 @@ description: "This page documents the 'BPF_KPROBE' libbpf eBPF macro, including
 The `BPF_KPROBE` macro makes it easier to write [kprobe](../../../linux/program-type/BPF_PROG_TYPE_KPROBE.md) programs.
 
 !!! note
-    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefor, the variable name `ctx` should not be reused in arguments or function body.
+    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefore, the variable name `ctx` should not be reused in arguments or function body.
 
 ## Definition
 
diff --git a/docs/ebpf-library/libbpf/ebpf/BPF_KSYSCALL.md b/docs/ebpf-library/libbpf/ebpf/BPF_KSYSCALL.md
index 395f0526..b4eddf05 100644
--- a/docs/ebpf-library/libbpf/ebpf/BPF_KSYSCALL.md
+++ b/docs/ebpf-library/libbpf/ebpf/BPF_KSYSCALL.md
@@ -45,7 +45,7 @@ Traditionally a program author would have to use the [`PT_REGS_SYSCALL_REGS`](PT
 The `BPF_KSYSCALL` macro allows you to write your program with an argument list, the macro will do the casting for you and accounts for the syscall wrapping.
 
 !!! note
-    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefor, the variable name `ctx` should not be reused in arguments or function body.
+    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefore, the variable name `ctx` should not be reused in arguments or function body.
 
 !!! warning
     At the moment `BPF_KSYSCALL` does not transparently handle all the calling convention quirks for the following syscalls:
diff --git a/docs/ebpf-library/libbpf/ebpf/BPF_PROG.md b/docs/ebpf-library/libbpf/ebpf/BPF_PROG.md
index 39f6f253..53838d78 100644
--- a/docs/ebpf-library/libbpf/ebpf/BPF_PROG.md
+++ b/docs/ebpf-library/libbpf/ebpf/BPF_PROG.md
@@ -35,7 +35,7 @@ Conventionally with these program contexts, the arguments to the program are put
 The `BPF_PROG` macro allows you to write your program with a normal function signature, the macro will then do the casting for you.
 
 !!! note
-    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefor, the variable name `ctx` should not be reused in arguments or function body.
+    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefore, the variable name `ctx` should not be reused in arguments or function body.
 
 !!! warning
     This macro assumes a 1 to 1 conversion between a `u64` and argument. However, the Sys V calling convention allows types such as structs of up to 16 bytes to be passed over 2 registers and thus two `u64`s in the context. That breaks the assumption and may lead to hard to resolve bugs. The [`BPF_PROG2`](BPF_PROG2.md) macro is the improved version of this one which does account for this. Its recommend to use the second version when you might be dealing with arguments larger than 8 bytes.
diff --git a/docs/ebpf-library/libbpf/ebpf/BPF_PROG2.md b/docs/ebpf-library/libbpf/ebpf/BPF_PROG2.md
index 7e1f68bc..45bb5e45 100644
--- a/docs/ebpf-library/libbpf/ebpf/BPF_PROG2.md
+++ b/docs/ebpf-library/libbpf/ebpf/BPF_PROG2.md
@@ -34,7 +34,7 @@ The `BPF_PROG2` macro allows you to write your program with a normal function si
 This macro also accounts for an edge case in the <nospell>Sys V</nospell> calling convention. When a function call is made, every argument will be put in specific registers. When a variable is to large to put in a register (8 bytes) it is often put on the stack and a pointer to it is passed instead (pointers being 8 bytes). However, the <nospell>Sys V</nospell> calling convention specifies that if a variable is between 8 and 16 bytes, it may be transferred using 2 registers instead, for a `struct{u64, u64}` for example. Since the context is a translation of the arguments passed, it to can use one or two slots depending on the type. The `BPF_PROG2` handles this in the background, which is what improved over the [`BPF_PROG`](BPF_PROG.md) version of this macro.
 
 !!! note
-    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefor, the variable name `ctx` should not be reused in arguments or function body.
+    The original context will stay available as `ctx`, if you ever wish to access it manually or need to pass it to a helper or kfunc. Therefore, the variable name `ctx` should not be reused in arguments or function body.
 
 ### Example
 
diff --git a/docs/ebpf-library/libbpf/ebpf/PT_REGS_PARM.md b/docs/ebpf-library/libbpf/ebpf/PT_REGS_PARM.md
index 5787635d..a082017e 100644
--- a/docs/ebpf-library/libbpf/ebpf/PT_REGS_PARM.md
+++ b/docs/ebpf-library/libbpf/ebpf/PT_REGS_PARM.md
@@ -28,7 +28,7 @@ SEC("kprobe.multi/__netif_receive_skb_core*")
 int bpf_prog1(struct pt_regs *ctx)
 {
 	/* attaches to kprobe __netif_receive_skb_core,
-	 * looks for packets on loobpack device and prints them
+	 * looks for packets on loopback device and prints them
 	 * (wildcard is used for avoiding symbol mismatch due to optimization)
 	 */
 	char devname[IFNAMSIZ];
diff --git a/docs/ebpf-library/libbpf/ebpf/__arg_ctx.md b/docs/ebpf-library/libbpf/ebpf/__arg_ctx.md
index 84d0b074..487ec391 100644
--- a/docs/ebpf-library/libbpf/ebpf/__arg_ctx.md
+++ b/docs/ebpf-library/libbpf/ebpf/__arg_ctx.md
@@ -14,7 +14,7 @@ The `__arg_ctx` macros is used to tag a function argument to tell the verifier t
 
 ## Usage
 
-This macro can be used to tag a function argument of a [global function](../../../linux/concepts/functions.md#function-by-function-verification) if you want to write that function in such a way that it can be re-used between different program types. Global functions are verified function-by-function, so the function can be verifier before any of its callers. The verifier therefore has to use type info to determine possible values. The verifier will already implicitly associate types such as `struct __sk_buff*` and `struct xdp_md*` with the program context and assert only the actual, valid context is passed. However, a function that can work with multiple program contexts needs to use `void *` to be able to compile, which means the verifier is missing type info. When this becomes an issue you can add the `__arg_ctx` macro to the function argument to tell the verifier that the argument is a program context. The verifier will treat the argument as a program context for all intents and purposes and it will enforce a valid context is passed on the call site.
+This macro can be used to tag a function argument of a [global function](../../../linux/concepts/functions.md#function-by-function-verification) if you want to write that function in such a way that it can be reused between different program types. Global functions are verified function-by-function, so the function can be verifier before any of its callers. The verifier therefore has to use type info to determine possible values. The verifier will already implicitly associate types such as `struct __sk_buff*` and `struct xdp_md*` with the program context and assert only the actual, valid context is passed. However, a function that can work with multiple program contexts needs to use `void *` to be able to compile, which means the verifier is missing type info. When this becomes an issue you can add the `__arg_ctx` macro to the function argument to tell the verifier that the argument is a program context. The verifier will treat the argument as a program context for all intents and purposes and it will enforce a valid context is passed on the call site.
 
 ### Example
 
diff --git a/docs/ebpf-library/libbpf/ebpf/__kconfig.md b/docs/ebpf-library/libbpf/ebpf/__kconfig.md
index ba993d32..956046e7 100644
--- a/docs/ebpf-library/libbpf/ebpf/__kconfig.md
+++ b/docs/ebpf-library/libbpf/ebpf/__kconfig.md
@@ -26,7 +26,7 @@ enum libbpf_tristate {
 
 This enum type is also provided by the `bpf_helpers.h` file. 
 
-This capability ties into CO-RE (Compile Once - Run Everywhere). Since the value is provided at load time it allows the user to write multiple variations / code paths that are enabled or disabled based on the value of, for example, in this case a kernel configuration option. Therefor allowing the same pre-compiled eBPF program to be loaded on different systems with different kernel configurations.
+This capability ties into CO-RE (Compile Once - Run Everywhere). Since the value is provided at load time it allows the user to write multiple variations / code paths that are enabled or disabled based on the value of, for example, in this case a kernel configuration option. Therefore allowing the same pre-compiled eBPF program to be loaded on different systems with different kernel configurations.
 
 If a value for a kernel configuration option is not found, the loader (library) will error out, unless the [`__weak`](__weak.md) attribute is also used.
 
diff --git a/docs/ebpf-library/libbpf/ebpf/bpf_core_read.md b/docs/ebpf-library/libbpf/ebpf/bpf_core_read.md
index dcb5663e..b709285a 100644
--- a/docs/ebpf-library/libbpf/ebpf/bpf_core_read.md
+++ b/docs/ebpf-library/libbpf/ebpf/bpf_core_read.md
@@ -41,7 +41,7 @@ struct some_value dst;
 bpf_core_read(&dst, sizeof(dst), a.c.d);
 ```
 
-Since `src` contains the field accesses, these fill be stored in the relocation entry so the actual offset can be adjusted. It is therefor important to not do the field access outside of the `bpf_core_read`:
+Since `src` contains the field accesses, these fill be stored in the relocation entry so the actual offset can be adjusted. It is therefore important to not do the field access outside of the `bpf_core_read`:
 
 ```c
 /* Incorrect */
diff --git a/docs/ebpf-library/libbpf/ebpf/index.md b/docs/ebpf-library/libbpf/ebpf/index.md
index ff82ec68..2837aef7 100644
--- a/docs/ebpf-library/libbpf/ebpf/index.md
+++ b/docs/ebpf-library/libbpf/ebpf/index.md
@@ -70,7 +70,7 @@ The file contains definitions for the following:
 
 ## [`bpf_endian.h`](https://github.com/libbpf/libbpf/blob/master/src/bpf_endian.h)
 
-The `bpf_endian.h` file contains macros for endianess conversion. It is useful when you need to convert data between host and network byte order.
+The `bpf_endian.h` file contains macros for endianness conversion. It is useful when you need to convert data between host and network byte order.
 
 The file contains definitions for the following:
 
diff --git a/docs/ebpf-library/libxdp/functions/xsk_ring_prod__tx_desc.md b/docs/ebpf-library/libxdp/functions/xsk_ring_prod__tx_desc.md
index ddbe5f4d..76b63133 100644
--- a/docs/ebpf-library/libxdp/functions/xsk_ring_prod__tx_desc.md
+++ b/docs/ebpf-library/libxdp/functions/xsk_ring_prod__tx_desc.md
@@ -10,7 +10,7 @@ This function allow to access a specific transmit descriptor in the **TX** ring.
 
 ### Returns
 
-`struct xdp_desc`, informations about the packet to be transmitted.
+`struct xdp_desc`, information about the packet to be transmitted.
 
 ## Usage
 
diff --git a/docs/ebpf-library/libxdp/libxdp.md b/docs/ebpf-library/libxdp/libxdp.md
index f8deda73..c35f6047 100644
--- a/docs/ebpf-library/libxdp/libxdp.md
+++ b/docs/ebpf-library/libxdp/libxdp.md
@@ -3,7 +3,7 @@
 libxdp is a light eBPF library who add 2 features for [XDP programs](../../linux/program-type/BPF_PROG_TYPE_XDP.md).
 
 - Load multiple programs on single network device using a "dispatcher program" thanks to [`freplace`](../../linux/program-type/BPF_PROG_TYPE_EXT.md)
-- Configuring [`AF_XDP`](../../linux/concepts/af_xdp.md) and functions to read and write on theses sockets
+- Configuring [`AF_XDP`](../../linux/concepts/af_xdp.md) and functions to read and write on these sockets
 
 You can check more information on the [libxdp readme](https://github.com/xdp-project/xdp-tools/blob/master/lib/libxdp/README.org).
 
diff --git a/docs/ebpf-library/scx/READ_ONCE.md b/docs/ebpf-library/scx/READ_ONCE.md
index 5daf43e7..7b3da319 100644
--- a/docs/ebpf-library/scx/READ_ONCE.md
+++ b/docs/ebpf-library/scx/READ_ONCE.md
@@ -43,7 +43,7 @@ static __always_inline void __read_once_size(const volatile void *p, void *res,
 
 Compilers will try to optimize code in any way possible within the constraints they are aware of. They may for example:
 
-* Keep the result of a memory read in a register and re-use it instead of re-reading the memory location. (caching)
+* Keep the result of a memory read in a register and reuse it instead of re-reading the memory location. (caching)
 * Reorder reads to improve cache locality (reordering)
 * Re-read from memory instead of keeping the value in a register (redoing)
 
diff --git a/docs/linux/concepts/af_xdp.md b/docs/linux/concepts/af_xdp.md
index 38879be6..af327d64 100644
--- a/docs/linux/concepts/af_xdp.md
+++ b/docs/linux/concepts/af_xdp.md
@@ -249,7 +249,7 @@ In the above diagram you can see our UMEM section, the 4 ring buffers, the kerne
 
 The ring buffers are used to communicate between the process and the kernel. If done correctly, it allows for a bi-directional data stream using the same pre-allocated memory blocks without the need for spin-locks or other synchronization techniques.
 
-The ring buffers are single-producer, single-consumer ring buffers. The rings consists of the actual array of descriptors (`#!c struct xdp_desc`), a `producer` and a `consumer`. In our diagram we refer to the `producer` as `head` and `consumer` as `tail` since those are the more typical terms used for queues/ring buffers. The kernel updates the `producer`/`head` of the RX and COMPLETION buffers and the process updated the `producer`/`head` of the TX and FILL buffers. The consumer watches for changes in the `producer`/`head`, if updated, it is safe to read the UMEM chunks between the `tail`/`consumer` and `producer`/`head`. The consumer increments the `tail`/`consumer` to indicate to the producer that the spot on the ring can be re-used. The descriptors in the ring contain a `addr` field which is the offset into the UMEM indicating the chunk, a `len` field indicating the length of any data in the chunk and a `flags` field.
+The ring buffers are single-producer, single-consumer ring buffers. The rings consists of the actual array of descriptors (`#!c struct xdp_desc`), a `producer` and a `consumer`. In our diagram we refer to the `producer` as `head` and `consumer` as `tail` since those are the more typical terms used for queues/ring buffers. The kernel updates the `producer`/`head` of the RX and COMPLETION buffers and the process updated the `producer`/`head` of the TX and FILL buffers. The consumer watches for changes in the `producer`/`head`, if updated, it is safe to read the UMEM chunks between the `tail`/`consumer` and `producer`/`head`. The consumer increments the `tail`/`consumer` to indicate to the producer that the spot on the ring can be reused. The descriptors in the ring contain a `addr` field which is the offset into the UMEM indicating the chunk, a `len` field indicating the length of any data in the chunk and a `flags` field.
 
 When we start all chunks are owned by the process, which means it can safely read and write without fear of race conditions.
 
diff --git a/docs/linux/concepts/functions.md b/docs/linux/concepts/functions.md
index 4bc2cbb7..c4e683e6 100644
--- a/docs/linux/concepts/functions.md
+++ b/docs/linux/concepts/functions.md
@@ -24,7 +24,7 @@ Until [:octicons-tag-24: v5.6](https://github.com/torvalds/linux/commit/51c39bb1
 
 Since [:octicons-tag-24: v5.6](https://github.com/torvalds/linux/commit/51c39bb1d5d105a02e29aa7960f0a395086e6342) a distinction is made between "static" and "global" functions. Static functions are functions marked with the `static` keyword in the C code, global functions regular non-static functions. Static functions are still verified as usual. But global functions undergo "function by function verification". This means that the verifier will verify every function once, and even out of order. So every function is verified exactly once, and not per-call site anymore. This change reduces verification times and complexity. But the verifier does impose a lot more limitations. 
 
-The verifier will assume no information about arguments, since it will not check every call site anymore. So even tough a function is only ever called with a `u32` of `123`, the verifier will assume the full `0`-`4294967295` are possible values. Therefor, functions might require more input checking to pass the verifier.
+The verifier will assume no information about arguments, since it will not check every call site anymore. So even tough a function is only ever called with a `u32` of `123`, the verifier will assume the full `0`-`4294967295` are possible values. Therefore, functions might require more input checking to pass the verifier.
 
 The verifier also limits the return type to always be scalar (a number). And the arguments to be pointer to a program context and scalars. This limitation on arguments was widen in later kernel releases, see later sections.
 
diff --git a/docs/linux/concepts/kfuncs.md b/docs/linux/concepts/kfuncs.md
index f5d336bd..6e70bd55 100644
--- a/docs/linux/concepts/kfuncs.md
+++ b/docs/linux/concepts/kfuncs.md
@@ -275,7 +275,7 @@ The verifier will guarantee that an iterator is destroyed by a function with the
 
 The `KF_ITER_NEXT` flag is used to indicate that the KFunc is used to advance an iterator. This means that the KFunc will take a pointer to an iterator and advance it to the next object.
 
-The verifier will enforce that a `KF_ITER_NEXT` KFunc is only called with an interator created a `KF_ITER_NEW` KFunc. Typically a `KF_ITER_NEW` KFunc will have a corresponding `KF_ITER_NEXT` KFunc, such pairs are easy to spot.
+The verifier will enforce that a `KF_ITER_NEXT` KFunc is only called with an iterator created a `KF_ITER_NEW` KFunc. Typically a `KF_ITER_NEW` KFunc will have a corresponding `KF_ITER_NEXT` KFunc, such pairs are easy to spot.
 
 ### `KF_ITER_DESTROY`
 
diff --git a/docs/linux/helper-function/bpf_map_lookup_elem.md b/docs/linux/helper-function/bpf_map_lookup_elem.md
index 25d1f59a..e370f256 100644
--- a/docs/linux/helper-function/bpf_map_lookup_elem.md
+++ b/docs/linux/helper-function/bpf_map_lookup_elem.md
@@ -33,7 +33,7 @@ Map value associated to _key_, or **NULL** if no entry was found.
 The `map` argument must be a pointer to a map definition and `key` must be a pointer to the key you
 wish to lookup.
 
-The return value will be a pointer to the map value or `NULL`. The value is a direct reference to the kernel memory where this map value is stored, not a copy. Therefor any modifications made to the value are automatically persisted without the need to call any additional helpers.
+The return value will be a pointer to the map value or `NULL`. The value is a direct reference to the kernel memory where this map value is stored, not a copy. Therefore any modifications made to the value are automatically persisted without the need to call any additional helpers.
 
 !!! warning
     modifying map values of non per-CPU maps is subject to race conditions, atomic instructions or spinlocks must be utilized to prevent race conditions if they are detrimental to your use case.
diff --git a/docs/linux/map-type/BPF_MAP_TYPE_ARRAY.md b/docs/linux/map-type/BPF_MAP_TYPE_ARRAY.md
index 27af5034..3bef5f0f 100644
--- a/docs/linux/map-type/BPF_MAP_TYPE_ARRAY.md
+++ b/docs/linux/map-type/BPF_MAP_TYPE_ARRAY.md
@@ -14,7 +14,7 @@ The array map type is a generic map type with no restrictions on the structure o
 
 While the [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) is essentially unrestricted, the [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must always be `4` indicating the key is a 32-bit unsigned integer.
 
-The value of [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) shouldn't exceed `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependant on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
+The value of [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) shouldn't exceed `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependent on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
 
 <!-- TODO link to generic page for attributes which are the same for every map type -->
 
diff --git a/docs/linux/map-type/BPF_MAP_TYPE_HASH.md b/docs/linux/map-type/BPF_MAP_TYPE_HASH.md
index fb0b3bcb..90f3123c 100644
--- a/docs/linux/map-type/BPF_MAP_TYPE_HASH.md
+++ b/docs/linux/map-type/BPF_MAP_TYPE_HASH.md
@@ -12,7 +12,7 @@ The hash map type is a generic map type with no restrictions on the structure of
 
 ## Attributes
 
-While the size of the key and value are essentially unrestricted, both [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) and [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must be at least zero and their combined size no larger than `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependant on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
+While the size of the key and value are essentially unrestricted, both [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) and [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must be at least zero and their combined size no larger than `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependent on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
 
 <!-- TODO link to generic page for attributes which are the same for every map type -->
 
diff --git a/docs/linux/map-type/BPF_MAP_TYPE_LRU_HASH.md b/docs/linux/map-type/BPF_MAP_TYPE_LRU_HASH.md
index 6af42360..963fedc7 100644
--- a/docs/linux/map-type/BPF_MAP_TYPE_LRU_HASH.md
+++ b/docs/linux/map-type/BPF_MAP_TYPE_LRU_HASH.md
@@ -29,7 +29,7 @@ When the `BPF_F_NO_COMMON_LRU` is set, every CPU gets its own 3-list LRU account
 
 ## Attributes
 
-While the size of the key and value are essentially unrestricted both [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) and [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must be at least larger than zero and their combined size plus implementation overhead no larger than `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependant on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
+While the size of the key and value are essentially unrestricted both [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) and [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must be at least larger than zero and their combined size plus implementation overhead no larger than `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependent on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
 
 ## Syscall commands
 
diff --git a/docs/linux/map-type/BPF_MAP_TYPE_PERCPU_HASH.md b/docs/linux/map-type/BPF_MAP_TYPE_PERCPU_HASH.md
index 091701a7..bd9d27d6 100644
--- a/docs/linux/map-type/BPF_MAP_TYPE_PERCPU_HASH.md
+++ b/docs/linux/map-type/BPF_MAP_TYPE_PERCPU_HASH.md
@@ -24,9 +24,9 @@ Since preemption is disabled during program execution, no other programs will be
 
 ## Attributes
 
-While the size of the key and value are essentially unrestricted both [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) and [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must be at least zero and their combined size no larger than `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependant on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
+While the size of the key and value are essentially unrestricted both [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) and [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) must be at least zero and their combined size no larger than `KMALLOC_MAX_SIZE`. `KMALLOC_MAX_SIZE` is the maximum size which can be allocated by the kernel memory allocator, its exact value being dependent on a number of factors. If this edge case is hit a `-E2BIG` [error number](https://man7.org/linux/man-pages/man3/errno.3.html) is returned to the [map create syscall](../syscall/BPF_MAP_CREATE.md).
 
-The [`max_entries`](../syscall/BPF_MAP_CREATE.md#max_entries) attribute indicates the max entries per-CPU so the actual memory size consumed is also dependant on the logical CPU count of the host.
+The [`max_entries`](../syscall/BPF_MAP_CREATE.md#max_entries) attribute indicates the max entries per-CPU so the actual memory size consumed is also dependent on the logical CPU count of the host.
 
 <!-- TODO link to generic page for attributes which are the same for every map type -->
 
diff --git a/docs/linux/map-type/BPF_MAP_TYPE_PERF_EVENT_ARRAY.md b/docs/linux/map-type/BPF_MAP_TYPE_PERF_EVENT_ARRAY.md
index 6914a574..be14a8c6 100644
--- a/docs/linux/map-type/BPF_MAP_TYPE_PERF_EVENT_ARRAY.md
+++ b/docs/linux/map-type/BPF_MAP_TYPE_PERF_EVENT_ARRAY.md
@@ -218,7 +218,7 @@ The `mmap` call, if all is well, should return a pointer to a memory address. Th
         * after reading this value.
         *
         * When the mapping is PROT_WRITE the @data_tail value should be
-        * written by userspace to reflect the last read data, after issueing
+        * written by userspace to reflect the last read data, after issuing
         * an smp_mb() to separate the data read from the ->data_tail store.
         * In this case the kernel will not over-write unread data.
         *
diff --git a/docs/linux/map-type/BPF_MAP_TYPE_RINGBUF.md b/docs/linux/map-type/BPF_MAP_TYPE_RINGBUF.md
index afcb99da..e1cb5407 100644
--- a/docs/linux/map-type/BPF_MAP_TYPE_RINGBUF.md
+++ b/docs/linux/map-type/BPF_MAP_TYPE_RINGBUF.md
@@ -16,7 +16,7 @@ This map consists of a singular ring as opposed to the per-CPU design of the `BP
 
 Since this map type does not have key-value pairs, and the communicated samples can be of any size, the [`key_size`](../syscall/BPF_MAP_CREATE.md#key_size) and [`value_size`](../syscall/BPF_MAP_CREATE.md#value_size) attributes have to both be set to `0`.
 
-The [`max_entries`](../syscall/BPF_MAP_CREATE.md#max_entries) attribute is used to specify the size of the ring-buffer in bytes. It must be a power of 2 and a multiple of the page size (typically `4096`), so `4096`, `8192`, `16384`, `32768`, ect.
+The [`max_entries`](../syscall/BPF_MAP_CREATE.md#max_entries) attribute is used to specify the size of the ring-buffer in bytes. It must be a power of 2 and a multiple of the page size (typically `4096`), so `4096`, `8192`, `16384`, `32768`, etc.
 
 ## Userspace map reading
 
diff --git a/docs/linux/program-type/BPF_PROG_TYPE_SOCK_OPS.md b/docs/linux/program-type/BPF_PROG_TYPE_SOCK_OPS.md
index b049b978..be58dcae 100644
--- a/docs/linux/program-type/BPF_PROG_TYPE_SOCK_OPS.md
+++ b/docs/linux/program-type/BPF_PROG_TYPE_SOCK_OPS.md
@@ -44,7 +44,7 @@ When invoked with this `op`, the program can overwrite the default RTO (retransm
 [:octicons-tag-24: v4.13](https://github.com/torvalds/linux/commit/13d3b1ebe28762c79e981931a41914fae5d04386)
 <!-- [/FEATURE_TAG] -->
 
-When invoked with this `op`, the program can overwrite the default initial advertized window (in packets) or -1 if default value should be used.
+When invoked with this `op`, the program can overwrite the default initial advertised window (in packets) or -1 if default value should be used.
 
 ### `BPF_SOCK_OPS_TCP_CONNECT_CB`
 <!-- [FEATURE_TAG](BPF_SOCK_OPS_TCP_CONNECT_CB) -->
@@ -189,7 +189,7 @@ This is just a notification, return value is discarded.
 [:octicons-tag-24: v5.10](https://github.com/torvalds/linux/commit/0813a841566f0962a5551be7749b43c45f0022a0)
 <!-- [/FEATURE_TAG] -->
 
-When the `BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG` flag is set with [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), the program is invoked with this `op` to write TCP options to the packet, the room for these options has been reserved in a previous invokation of the program with the `BPF_SOCK_OPS_HDR_OPT_LEN_CB` op.
+When the `BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG` flag is set with [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), the program is invoked with this `op` to write TCP options to the packet, the room for these options has been reserved in a previous invocation of the program with the `BPF_SOCK_OPS_HDR_OPT_LEN_CB` op.
 
 The arguments in the context will have the following meanings:
 
@@ -212,7 +212,7 @@ The [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md) can also be use
 Called when skb is passing through device layer when `SK_BPF_CB_TX_TIMESTAMPING` feature is on. Which is done by setting a socket option `bpf_setsockopt(SK_BPF_CB_FLAGS, SK_BPF_CB_TX_TIMESTAMPING)` or calling [`bpf_sock_ops_enable_tx_tstamp`](../kfuncs/bpf_sock_ops_enable_tx_tstamp.md) on the socket.
 
 !!! warning
-    This sock op is called without taking a socket lock and will therefor not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
+    This sock op is called without taking a socket lock and will therefore not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
 
 ### `BPF_SOCK_OPS_TSTAMP_SND_SW_CB`
 
@@ -223,7 +223,7 @@ Called when skb is passing through device layer when `SK_BPF_CB_TX_TIMESTAMPING`
 Called when skb is about to send to the NIC when `SK_BPF_CB_TX_TIMESTAMPING` feature is on. Which is done by setting a socket option `bpf_setsockopt(SK_BPF_CB_FLAGS, SK_BPF_CB_TX_TIMESTAMPING)` or calling [`bpf_sock_ops_enable_tx_tstamp`](../kfuncs/bpf_sock_ops_enable_tx_tstamp.md) on the socket.
 
 !!! warning
-    This sock op is called without taking a socket lock and will therefor not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
+    This sock op is called without taking a socket lock and will therefore not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
 
 
 ### `BPF_SOCK_OPS_TSTAMP_SND_HW_CB`
@@ -235,7 +235,7 @@ Called when skb is about to send to the NIC when `SK_BPF_CB_TX_TIMESTAMPING` fea
 Called in hardware phase when `SK_BPF_CB_TX_TIMESTAMPING` feature is on. Which is done by setting a socket option `bpf_setsockopt(SK_BPF_CB_FLAGS, SK_BPF_CB_TX_TIMESTAMPING)` or calling [`bpf_sock_ops_enable_tx_tstamp`](../kfuncs/bpf_sock_ops_enable_tx_tstamp.md) on the socket.
 
 !!! warning
-    This sock op is called without taking a socket lock and will therefor not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
+    This sock op is called without taking a socket lock and will therefore not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
 
 
 ### `BPF_SOCK_OPS_TSTAMP_ACK_CB`
@@ -247,7 +247,7 @@ Called in hardware phase when `SK_BPF_CB_TX_TIMESTAMPING` feature is on. Which i
 Called when all the <nospell>SKBs</nospell> in the same `sendmsg` call are acked when [`SK_BPF_CB_TX_TIMESTAMPING`](../kfuncs/bpf_sock_ops_enable_tx_tstamp.md) feature is on. Which is done by setting a socket option `bpf_setsockopt(SK_BPF_CB_FLAGS, SK_BPF_CB_TX_TIMESTAMPING)` or calling [`bpf_sock_ops_enable_tx_tstamp`](../kfuncs/bpf_sock_ops_enable_tx_tstamp.md) on the socket.
 
 !!! warning
-    This sock op is called without taking a socket lock and will therefor not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
+    This sock op is called without taking a socket lock and will therefore not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
 
 
 ### `BPF_SOCK_OPS_TSTAMP_SENDMSG_CB`
@@ -259,7 +259,7 @@ Called when all the <nospell>SKBs</nospell> in the same `sendmsg` call are acked
 Called when every `sendmsg` syscall is triggered. It's used to correlate `sendmsg` timestamp with corresponding `tskey`.
 
 !!! warning
-    This sock op is called without taking a socket lock and will therefor not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
+    This sock op is called without taking a socket lock and will therefore not be able to use the following helper functions: [`bpf_setsockopt`](../helper-function/bpf_setsockopt.md), [`bpf_getsockopt`](../helper-function/bpf_getsockopt.md), [`bpf_sock_ops_cb_flags_set`](../helper-function/bpf_sock_ops_cb_flags_set.md), [`bpf_load_hdr_opt`](../helper-function/bpf_load_hdr_opt.md). They will always return `-EOPNOTSUPP` instead of failing verification.
 
 ## Context
 
@@ -359,7 +359,7 @@ This field will indicate the current operation, see the [ops section](#ops) for
 
 [:octicons-tag-24: v4.16](https://github.com/torvalds/linux/commit/de525be2ca2734865d29c4b67ddd29913b214906)
 
-This field is an array of 4 `__u32` values, used by some operations to provide additional information. The meaning of the arguments is dependant on the `op`.
+This field is an array of 4 `__u32` values, used by some operations to provide additional information. The meaning of the arguments is dependent on the `op`.
 
 ### `reply`
 
diff --git a/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS.md b/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS.md
index d1f3e330..b63afe18 100644
--- a/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS.md
+++ b/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS.md
@@ -62,7 +62,7 @@ The kernel has now allocated memory for one instance of the struct_ops struct an
     // SPDX-License-Identifier: GPL-2.0
     /* Copyright (c) 2019 Facebook */
 
-    /* WARNING: This implemenation is not necessarily the same
+    /* WARNING: This implementation is not necessarily the same
     * as the tcp_dctcp.c.  The purpose is mainly for testing
     * the kernel BPF logic.
     */
diff --git a/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/hid_bpf_ops.md b/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/hid_bpf_ops.md
index 2f315faa..89df20c6 100644
--- a/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/hid_bpf_ops.md
+++ b/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/hid_bpf_ops.md
@@ -61,7 +61,7 @@ If `0`, the current struct_ops will be registered at the end of the list of stru
 
 `#!c int (*hid_device_event)(struct hid_bpf_ctx *ctx, enum hid_report_type report_type, u64 source)`
 
-This function/program is called whenever an event is coming in from the device. The callback is executed in the context of an interrupt and may therefor not be [sleepable](../../syscall/BPF_PROG_LOAD.md#bpf_f_sleepable).
+This function/program is called whenever an event is coming in from the device. The callback is executed in the context of an interrupt and may therefore not be [sleepable](../../syscall/BPF_PROG_LOAD.md#bpf_f_sleepable).
 
 **Parameters**
 
diff --git a/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/tcp_congestion_ops.md b/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/tcp_congestion_ops.md
index 62a5f243..c00ca9a8 100644
--- a/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/tcp_congestion_ops.md
+++ b/docs/linux/program-type/BPF_PROG_TYPE_STRUCT_OPS/tcp_congestion_ops.md
@@ -528,7 +528,7 @@ This example is sourced from [https://elixir.bootlin.com/linux/v6.13/source/tool
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (c) 2019 Facebook */
 
-/* WARNING: This implemenation is not necessarily the same
+/* WARNING: This implementation is not necessarily the same
  * as the tcp_dctcp.c.  The purpose is mainly for testing
  * the kernel BPF logic.
  */
diff --git a/docs/linux/program-type/BPF_PROG_TYPE_XDP.md b/docs/linux/program-type/BPF_PROG_TYPE_XDP.md
index 3e8c1b25..84fc8268 100644
--- a/docs/linux/program-type/BPF_PROG_TYPE_XDP.md
+++ b/docs/linux/program-type/BPF_PROG_TYPE_XDP.md
@@ -50,7 +50,7 @@ This field contains a pointer to the end of the packet data. The verifier will e
 
 [:octicons-tag-24: v4.15](https://github.com/torvalds/linux/commit/de8f3a83b0a0fddb2cf56e7a718127e9619ea3da)
 
-This field contains a pointer to the start of a metadata region in the packet memory. By default, no metadata room is available, so the value of `data_meta` and `data` will be the same. The XDP program can request metadata with the [`bpf_xdp_adjust_meta`](../helper-function/bpf_xdp_adjust_meta.md) helper, on success `data_meta` is updated so it is not less then `data`. The room between `data_meta` and `data` is freely useable by the XDP program.
+This field contains a pointer to the start of a metadata region in the packet memory. By default, no metadata room is available, so the value of `data_meta` and `data` will be the same. The XDP program can request metadata with the [`bpf_xdp_adjust_meta`](../helper-function/bpf_xdp_adjust_meta.md) helper, on success `data_meta` is updated so it is not less then `data`. The room between `data_meta` and `data` is freely usable by the XDP program.
 
 If the packet with metadata is passed to the kernel, that metadata will be available in the [`__sk_buff`](../program-context/__sk_buff.md) via its [`data_meta`](../program-context/__sk_buff.md#data_meta) and `data` fields.
 
@@ -81,7 +81,7 @@ This field is read-only and contains the network interface index the packet has
 
 [:octicons-tag-24: v5.18](https://github.com/torvalds/linux/commit/c2f2cdbeffda7b153c19e0f3d73149c41026c0db)
 
-An increasingly common performance optimization technique is to use larger packets and to bulk process them (Jumbo packets, GRO, BIG-TCP). It might therefor happen that packets get larger than a single memory page or that we want to glue multiple already allocated packets together. This breaks the existing assumption XDP programs have of all the packet data living in a linear area between `data` and `data_end`. 
+An increasingly common performance optimization technique is to use larger packets and to bulk process them (Jumbo packets, GRO, BIG-TCP). It might therefore happen that packets get larger than a single memory page or that we want to glue multiple already allocated packets together. This breaks the existing assumption XDP programs have of all the packet data living in a linear area between `data` and `data_end`. 
 
 In order to offer support and not break existing programs, the concept of "XDP fragment aware" programs was introduced. XDP program authors writing such programs can compare the length between the `data` and `data_end` pointer and the output of [`bpf_xdp_get_buff_len`](../helper-function/bpf_xdp_get_buff_len.md). If the XDP program needs to work with data beyond the linear portion it should use the [`bpf_xdp_load_bytes`](../helper-function/bpf_xdp_load_bytes.md) and [`bpf_xdp_store_bytes`](../helper-function/bpf_xdp_store_bytes.md) helpers.
 
diff --git a/docs/linux/syscall/BPF_ENABLE_STATS.md b/docs/linux/syscall/BPF_ENABLE_STATS.md
index a2b415bf..6760f216 100644
--- a/docs/linux/syscall/BPF_ENABLE_STATS.md
+++ b/docs/linux/syscall/BPF_ENABLE_STATS.md
@@ -20,7 +20,7 @@ When enabled, the kernel will start to update the `run_time_ns` and `run_cnt` fi
 
 The `run_time_ns` value holds the accumulated amount of nano seconds the BPF program has ran and the `run_cnt` the amount of times it ran. Users might be interested in these values for the sake of monitoring the amount of CPU time BPF programs take up or to benchmark programs under real world conditions.
 
-These statistics are not enabled by default since BPF programs might be called quite frequently and recording this information increases the overhead of each BPF program run. It is therefor recommended to not permanently enable this feature in production environments or to do so when CPU usage can be spared.
+These statistics are not enabled by default since BPF programs might be called quite frequently and recording this information increases the overhead of each BPF program run. It is therefore recommended to not permanently enable this feature in production environments or to do so when CPU usage can be spared.
 
 The typical usage pattern would be:
 
diff --git a/docs/linux/syscall/BPF_LINK_CREATE.md b/docs/linux/syscall/BPF_LINK_CREATE.md
index 30a81e71..c4779a8b 100644
--- a/docs/linux/syscall/BPF_LINK_CREATE.md
+++ b/docs/linux/syscall/BPF_LINK_CREATE.md
@@ -514,7 +514,7 @@ The expected <nospell>mprog</nospell> revision, to avoid unexpected behavior in
 
 This section describes the possible values and meanings for the `attach_type` attribute. These values are the same as used in the [`BPF_PROG_ATTACH`](BPF_PROG_ATTACH.md) command and the [`expected_attach_type`](BPF_PROG_LOAD.md#expected_attach_type) field of the [`BPF_PROG_LOAD`](BPF_PROG_LOAD.md) command.
 
-The attach type is often used to communicate a specialization for a program type, for example if the program should attach to the ingress or egress. Since the hook locations will differ, the capabilities of the program may as well. Please check the pages of the program types for details about these attach type dependant limitations.
+The attach type is often used to communicate a specialization for a program type, for example if the program should attach to the ingress or egress. Since the hook locations will differ, the capabilities of the program may as well. Please check the pages of the program types for details about these attach type dependent limitations.
 
 ### `BPF_CGROUP_INET_INGRESS`
 
diff --git a/docs/linux/syscall/BPF_MAP_GET_NEXT_KEY.md b/docs/linux/syscall/BPF_MAP_GET_NEXT_KEY.md
index e5749268..83a646e0 100644
--- a/docs/linux/syscall/BPF_MAP_GET_NEXT_KEY.md
+++ b/docs/linux/syscall/BPF_MAP_GET_NEXT_KEY.md
@@ -15,7 +15,7 @@ The `BPF_MAP_GET_NEXT_KEY` command is used to iterate over the keys of a map.
 
 If the given `key` isn't found within the map, `0` is returned and the value pointed to by `next_key` will be set to the first key in the map. 
 
-If the given `key` is found withing the map, `0` is returned and the value pointed to by `next_key` will be set to the key after the current key.
+If the given `key` is found within the map, `0` is returned and the value pointed to by `next_key` will be set to the key after the current key.
 
 If the given `key` is found within the map and it is the last key, an error number of `-ENOENT` will be returned.
 
diff --git a/docs/linux/syscall/BPF_MAP_UPDATE_ELEM.md b/docs/linux/syscall/BPF_MAP_UPDATE_ELEM.md
index 5cf4362c..5e5b0de7 100644
--- a/docs/linux/syscall/BPF_MAP_UPDATE_ELEM.md
+++ b/docs/linux/syscall/BPF_MAP_UPDATE_ELEM.md
@@ -42,7 +42,7 @@ This flag has a value of `0`, so setting it together with another flag has no im
 If this flag is set, the command will make sure that the given key doesn't exist yet. If the same key already exists when this command is executed the `-EEXIST` error number will be returned.
 
 !!! note
-    Array map types are always pre-allocated and have all keys from `0` to `max_entries`-`1` set to zero, so commands with this flag set will alway fail.
+    Array map types are always pre-allocated and have all keys from `0` to `max_entries`-`1` set to zero, so commands with this flag set will always fail.
 
 #### `BPF_EXISTS`
 
diff --git a/docs/linux/syscall/BPF_OBJ_GET_INFO_BY_FD.md b/docs/linux/syscall/BPF_OBJ_GET_INFO_BY_FD.md
index 7915e37e..19a8f9f3 100644
--- a/docs/linux/syscall/BPF_OBJ_GET_INFO_BY_FD.md
+++ b/docs/linux/syscall/BPF_OBJ_GET_INFO_BY_FD.md
@@ -16,7 +16,7 @@ This command will return `0` on success or a error number (negative integer) if
 
 ## Usage
 
-This syscall command returns information about the BPF object indicated by `bpf_fd`. The structure of the returned information is dependant on the object type. More on this in the [info structures](#info-structures) section.
+This syscall command returns information about the BPF object indicated by `bpf_fd`. The structure of the returned information is dependent on the object type. More on this in the [info structures](#info-structures) section.
 
 This syscall is typically used by inspection tools to get information about loaded objects that you would normally "know" if you were the author or loader of a given object. 
 
@@ -43,7 +43,7 @@ This field indicates the size of the buffer which `info` points to and will be c
 
 ### `info`
 
-This field indicates a memory region to which the kernel will write the requested information, the structure of which is dependant on the object type to which `bpf_fd` refers (see [info structures](#info-structures)). This field should be a pointer.
+This field indicates a memory region to which the kernel will write the requested information, the structure of which is dependent on the object type to which `bpf_fd` refers (see [info structures](#info-structures)). This field should be a pointer.
 
 ## Info structures
 
diff --git a/docs/linux/syscall/BPF_PROG_LOAD.md b/docs/linux/syscall/BPF_PROG_LOAD.md
index e8a0aed8..e07debcd 100644
--- a/docs/linux/syscall/BPF_PROG_LOAD.md
+++ b/docs/linux/syscall/BPF_PROG_LOAD.md
@@ -155,7 +155,7 @@ This attribute specifies the network interface index the user intends to attach
 
 [:octicons-tag-24: v4.17](https://github.com/torvalds/linux/commit/5e43f899b03a3492ce5fc44e8900becb04dae9c0)
 
-This attribute specifies the attach type the user expects to use when attaching the program. For certain program types, the attach type may changes aspects like the context type that will be given, the meaning of return values, and which helper function are or are not available. Therefor the verifier must know the attach type during loading time to enforce correct behavior of the program to be loaded.
+This attribute specifies the attach type the user expects to use when attaching the program. For certain program types, the attach type may changes aspects like the context type that will be given, the meaning of return values, and which helper function are or are not available. Therefore the verifier must know the attach type during loading time to enforce correct behavior of the program to be loaded.
 
 The expected attach type is known to be important in the following cases:
 
@@ -163,7 +163,7 @@ The expected attach type is known to be important in the following cases:
 * For `BPF_PROG_TYPE_TRACING` programs the attach type determine access to helper calls
 * For `BPF_PROG_TYPE_CGROUP_SOCK_ADDR` programs the verifier restricts valid return values depending on attach type
 * For `BPF_PROG_TYPE_CGROUP_SKB` programs the verifier restricts valid return values depending on attach type
-* For `BPF_PROG_TYPE_CGROUP_SOCKOPT` programs the attach type determines accessability for certain context fields and helper functions.
+* For `BPF_PROG_TYPE_CGROUP_SOCKOPT` programs the attach type determines accessibility for certain context fields and helper functions.
 * Only `BPF_PROG_TYPE_XDP` programs with `BPF_XDP_CPUMAP` attach type can be added to the values of `BPF_MAP_TYPE_CPUMAP` maps
 * Only `BPF_PROG_TYPE_XDP` programs with `BPF_XDP_DEVMAP` attach type can be added to the values of `BPF_MAP_TYPE_DEVMAP` maps
 
diff --git a/docs/linux/syscall/BPF_PROG_TEST_RUN.md b/docs/linux/syscall/BPF_PROG_TEST_RUN.md
index 104353dd..d721d005 100644
--- a/docs/linux/syscall/BPF_PROG_TEST_RUN.md
+++ b/docs/linux/syscall/BPF_PROG_TEST_RUN.md
@@ -112,7 +112,7 @@ This field is not supported for the following program types:
 
 [:octicons-tag-24: v4.12](https://github.com/torvalds/linux/commit/1cf1cae963c2e6032aebe1637e995bc2f5d330f4)
 
-This field indicates how long the execution of the program took in nanoseconds. If `repeat` is larger than 1, the field will contain the avarage per-invokation run time for all repetitions.
+This field indicates how long the execution of the program took in nanoseconds. If `repeat` is larger than 1, the field will contain the average per-invokation run time for all repetitions.
 
 This field is not supported for the following program types:
 
diff --git a/hooks/links_in_code.py b/hooks/links_in_code.py
index 211d5cb4..93ea4928 100644
--- a/hooks/links_in_code.py
+++ b/hooks/links_in_code.py
@@ -123,7 +123,7 @@ def convert_links_in_spans(self, spans):
                 textElem.text = spans[i].text[ii+1:ji]
                 aElem.insert(0, textElem)
 
-                # Make a new span with the same calss as the original span
+                # Make a new span with the same class as the original span
                 # Add the text after the ')' to it.
                 postElem = etree.Element('span', attrib={'class': spans[i].get('class')})
                 postElem.text = spans[i].text[ki+1:]
diff --git a/hooks/mdx_outline.py b/hooks/mdx_outline.py
index 8688f12c..1b62064c 100644
--- a/hooks/mdx_outline.py
+++ b/hooks/mdx_outline.py
@@ -123,7 +123,7 @@
 This is a rewrite of the 
 [mdx_addsection extension](http://git.constantvzw.org/?p=aa.core.git;a=blob;f=aacore/mdx_addsections.py;h=969e520a42b0018a2c4b74889fecc83a7dd7704a;hb=HEAD) 
 we've written for [active archives](http://activearchives.org). The first
-version had a bug with non hierachical heading structures. This is no longer a
+version had a bug with non hierarchical heading structures. This is no longer a
 problem: a couple of weeks ago, Jesse Dhillon pushed to github a similar plugin
 which fixes the problem. Thanks to him, mdx_outline no longer has the problem.
 
diff --git a/tools/mtu-calc/drivers.go b/tools/mtu-calc/drivers.go
index 72ea332e..b579fe98 100644
--- a/tools/mtu-calc/drivers.go
+++ b/tools/mtu-calc/drivers.go
@@ -163,7 +163,7 @@ func calcDPAAMTU(v vars) int {
 }
 
 func calcDPAA2MTU(v vars) int {
-	// TODO: figure out typical priv->tx_data_offset which is recieved from the NIC
+	// TODO: figure out typical priv->tx_data_offset which is received from the NIC
 	// without it we can't calculate the MTU
 	return 0
 }
diff --git a/tools/spellcheck/main.go b/tools/spellcheck/main.go
index 10a51c92..2d08addb 100644
--- a/tools/spellcheck/main.go
+++ b/tools/spellcheck/main.go
@@ -163,7 +163,7 @@ func checkFile(path string) error {
 				"nav",
 				// Ignore code/quotes in code tags
 				"code",
-				// Ignore anyting inside the custom <nospell> tag
+				// Ignore anything inside the custom <nospell> tag
 				"nospell":
 				return skipSubtree
 			case "head":
@@ -224,7 +224,7 @@ func checkFile(path string) error {
 						break
 					}
 
-					// We should't get these in terse mode, but just in case
+					// We shouldn't get these in terse mode, but just in case
 					if strings.HasPrefix(line, "*") {
 						continue
 					}