Re: [PATCH] mm: fix typos in various comments

From: David Hildenbrand (Arm)

Date: Tue Sep 22 2026 - 07:55:24 EST


On 9/22/26 05:18, Zhijian Han wrote:
> Fix spelling errors found by codespell in several mm source files:
>
> - "aray" -> "array" in include/linux/mm.h
> - "indiciate" -> "indicate" in include/linux/mm_types.h
> - "aggresive" -> "aggressive" in include/linux/mm_types.h
> - "progated" -> "propagated" in mm/huge_memory.c
> - "Pressumably" -> "Presumably" in mm/hugetlb.c
> - "fime" -> "time" in mm/hugetlb.c
> - "farest" -> "farthest" in mm/list_lru.c
> - "trivally" -> "trivially" in mm/madvise.c
> - "atmost" -> "at most" in mm/memcontrol.c
> - "splited" -> "split" in mm/memory-failure.c
> - "appliable" -> "applicable" in mm/memory.c
> - "incase" -> "in case" in mm/page_io.c
> - "contigous" -> "contiguous" in mm/vmalloc.c
> - "probablity" -> "probability" in mm/kfence/core.c
> - "widnow" -> "window" in mm/damon/core.c
> - "makrs" -> "marks" in mm/damon/core.c
> - "possesss" -> "possesses" in mm/util.c
>
> No functional changes.
>
> Signed-off-by: Zhijian Han <hanzhijian1991@xxxxxxxxx>
> ---
> include/linux/mm.h | 2 +-
> include/linux/mm_types.h | 4 ++--
> mm/damon/core.c | 4 ++--
> mm/huge_memory.c | 2 +-
> mm/hugetlb.c | 4 ++--
> mm/kfence/core.c | 2 +-
> mm/list_lru.c | 2 +-
> mm/madvise.c | 2 +-
> mm/memcontrol.c | 2 +-
> mm/memory-failure.c | 2 +-
> mm/memory.c | 2 +-
> mm/page_io.c | 2 +-
> mm/util.c | 2 +-
> mm/vmalloc.c | 2 +-
> 14 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 87feaa5a2..5b2215e24 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4501,7 +4501,7 @@ static inline void mmap_action_simple_ioremap(struct vm_area_desc *desc,
> * @desc: The VMA descriptor for the VMA requiring kernel pags to be mapped.
> * @start: The virtual address from which to map them.
> * @pages: An array of struct page pointers describing the memory to map.
> - * @nr_pages: The number of entries in the @pages aray.
> + * @nr_pages: The number of entries in the @pages array.
> */
> static inline void mmap_action_map_kernel_pages(struct vm_area_desc *desc,
> unsigned long start, struct page **pages,
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 939b5ea8c..6c21bab3b 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -759,7 +759,7 @@ static inline struct anon_vma_name *anon_vma_name_alloc(const char *name)
> /*
> * While __vma_enter_locked() is working to ensure are no read-locks held on a
> * VMA (either while acquiring a VMA write lock or marking a VMA detached) we
> - * set the VM_REFCNT_EXCLUDE_READERS_FLAG in vma->vm_refcnt to indiciate to
> + * set the VM_REFCNT_EXCLUDE_READERS_FLAG in vma->vm_refcnt to indicate to
> * vma_start_read() that the reference count should be left alone.
> *
> * See the comment describing vm_refcnt in vm_area_struct for details as to
> @@ -1968,7 +1968,7 @@ enum {
> /*
> * MMF_HAS_PINNED: Whether this mm has pinned any pages. This can be either
> * replaced in the future by mm.pinned_vm when it becomes stable, or grow into
> - * a counter on its own. We're aggresive on this bit for now: even if the
> + * a counter on its own. We're aggressive on this bit for now: even if the
> * pinned pages were unpinned later on, we'll still keep this bit set for the
> * lifecycle of this mm, just for simplicity.
> */
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 644daf5a1..c01b7e2a1 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2328,7 +2328,7 @@ static bool damos_valid_target(struct damon_ctx *c, struct damon_region *r,
> * This function checks if a given region should be skipped or not for the
> * reason. If only the starting part of the region has previously charged,
> * this function splits the region into two so that the second one covers the
> - * area that not charged in the previous charge widnow, and return true. The
> + * area that not charged in the previous charge window, and return true. The

"that not" sound weird. Fix that while at it.

Apart from that LGTM.

--
Cheers,

David